Erik de Castro Lopo wrote:
> Hi all,
>
> I'm doing some systems programming where I need to use threads
> (standard threads, not cothreads), signals and events. The program
> has a couple of things to do:
>
>  a) Start program X, do a wait on its pid and restart X if it dies
>     and log information to syslog.
>  b) Periodically run other system checks and log results to syslog.
>     Certain types of system failures need to be communicated to
>     program X so that it can modify its behaviour.
>  c) Catch SIGHUP, and on reception, kill program X (send SIGHUP first
>     and if that doesn't work SIGTERM and finally SIGKILL) and then
>     exit itself.
>
> Since the system checks can take some time (mostly waiting for the
> kernel to do stuff rather than intensive processing) and program X
> needs to be restarted immediately if it dies, using threads seems 
> to be an obvious solution.
>
> However, reading between the lines of thread.mli suggests that
> signals should be blocked on all threads but one which catches
> signals using Thread.wait_signal and then sends events using the
> Event module to the other threads.
>
> This makes for four threads:
>
>  - Main thread which waits for SIGHUP and sends an Event when it
>    does.
>  - Monitor thread which waits for program X to exit using
>    Thread.wait_pid.
>  - A syscheck thread which pretty much does its thing and log its
>    results by sending an Event to the logger thread.
>  - Logger thread which receives events from the other threads and
>    writes to syslog.
>
> The problem with the above is that the monitor thread needs to wait
> on both a pid and an Event and I can't see any way to do that.
>
> Anybody have any suggestions? This is on Linux btw.
>
> Cheers,
> Erik
>   
Forks is more suitable for this task.