caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Threads, Signals and Events
@ 2008-02-14 22:19 Erik de Castro Lopo
  2008-02-15  6:47 ` [Caml-list] " Christophe Raffalli
  2008-02-15  8:18 ` SerP
  0 siblings, 2 replies; 3+ messages in thread
From: Erik de Castro Lopo @ 2008-02-14 22:19 UTC (permalink / raw)
  To: Caml-list

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
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"An older MS internal whitepaper from August 2000 on switching
Hotmail, which MS acquired in 1997, from front-end servers
running FreeBSD and back-end database servers running Solaris
to a whole farm running Win2K, reads like a veritable sales
brochure for UNIX"
-- http://www.theregister.co.uk/content/4/28226.html


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Caml-list] Threads, Signals and Events
  2008-02-14 22:19 Threads, Signals and Events Erik de Castro Lopo
@ 2008-02-15  6:47 ` Christophe Raffalli
  2008-02-15  8:18 ` SerP
  1 sibling, 0 replies; 3+ messages in thread
From: Christophe Raffalli @ 2008-02-15  6:47 UTC (permalink / raw)
  To: Erik de Castro Lopo; +Cc: Caml-list


[-- Attachment #1.1: Type: text/plain, Size: 1495 bytes --]

Erik de Castro Lopo a écrit :
> 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.
>
>   
Why not processes and fork ?

Christophe

-- 
Christophe Raffalli
Universite de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tel: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution 
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------


[-- Attachment #1.2: Christophe_Raffalli.vcf --]
[-- Type: text/x-vcard, Size: 310 bytes --]

begin:vcard
fn:Christophe Raffalli
n:Raffalli;Christophe
org:LAMA (UMR 5127)
email;internet:christophe.raffalli@univ-savoie.fr
title;quoted-printable:Ma=C3=AEtre de conf=C3=A9rences
tel;work:+33 4 79 75 81 03
note:http://www.lama.univ-savoie.fr/~raffalli
x-mozilla-html:TRUE
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Caml-list] Threads, Signals and Events
  2008-02-14 22:19 Threads, Signals and Events Erik de Castro Lopo
  2008-02-15  6:47 ` [Caml-list] " Christophe Raffalli
@ 2008-02-15  8:18 ` SerP
  1 sibling, 0 replies; 3+ messages in thread
From: SerP @ 2008-02-15  8:18 UTC (permalink / raw)
  Cc: Caml-list

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-02-15  8:18 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-14 22:19 Threads, Signals and Events Erik de Castro Lopo
2008-02-15  6:47 ` [Caml-list] " Christophe Raffalli
2008-02-15  8:18 ` SerP

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).