Re: 4.0 showstopper?

[Jan-Henrik Haukeland]

Christian Hopp <address@hidden> writes:

> We should plan for the next release to find a way to prevent
> possible race conditions by making all those function reentrant like
> it done for sendmail.c.  Now preventing global data is more
> important than before.  

Yes and no. OK, we have added a new wait_start() thread which
complicate stuff, but I absolutely belive that previous version of
monit will have many of the same race condition problems with
signals. But, yes, absolutely, global data must be protected, actually
the best thing to do is to have *no* global data at all and instead
pass shared data as parameters to functions, this way you will have a
reentrant system and probably a thread-safe system.

> Or we might want to rethink the whole multithreadded aspect in a
> highly critcal application like monit.  => Let me say it this:
>
>   Is multithreaded code anyhow appropriate for system critical
>   applications?

According to Alan Cox, "threads are for those that cannot program a
state machine". That might be true, at least on a one-cpu system. But
programming a state machine is hard and it's much easier to design and
program a system with threads. For instance it's easy to start monit's
httpd server in it's own thread. It cannot run in it's own process,
because you will lose important shared information, such as the
servicelist content. (I tried that in the 2.4 or 2.5 monit version and
it didn't work well). (Shared memory is an option but ugh, no-way
hosay :)

One option could be to rewrite monit to run in a big while-loop and do
monitoring *and* http in the same process.

while(true) {

 do_monitor(); // Call validate
 do_httpd(); // accept, parse and respond

}
 
do_validate() must not block and must take a very short time, maybe
only check one service per loop.

But summa summarum, I think we are better off by using threads. We
must only rememeber do it right :) Besides many of the latest problems
(except sendmail) was not directly related to threads but to signals.

-- 
Jan-Henrik Haukeland