[Caml-list] SIGTERM signal in multithreaded application

[Caml-list] SIGTERM signal in multithreaded application

[Basile STARYNKEVITCH]

Dear All

while working on  POESIA - www.poesia-filter.org ; see CVS code under
http://www2.poesia-filter.org:8000/ 

I notice that (with the native ocamlopt 3.06 compiler) on my Linux/x86
Debian/Sid (2.4.20 kernel, glibc 2.3.1)

When a multithreaded process is sent a SIGTERM or SIGINT signal
(either by a ^C on the terminal, or by the kill command) every thread
executes the signal handler with a negative signal number, and the
Sys.sigterm is -11 (negative eleven)

Is it possible to code so that only the main thread recieves a SIGTERM
signal and not all threads? Is this a Linux pthread or a OCaml runtime
system issue?

(I don't master all the subtilities of Linux threads, in particular
w.r.t signals).

-- 

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
alias: basile<at>tunes<dot>org 
8, rue de la Faïencerie, 92340 Bourg La Reine, France
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] SIGTERM signal in multithreaded application

[Gerd Stolpmann]

Am Don, 2003-02-13 um 23.01 schrieb Basile STARYNKEVITCH:
> Dear All
> 
> while working on  POESIA - www.poesia-filter.org ; see CVS code under
> http://www2.poesia-filter.org:8000/ 
> 
> I notice that (with the native ocamlopt 3.06 compiler) on my Linux/x86
> Debian/Sid (2.4.20 kernel, glibc 2.3.1)
> 
> When a multithreaded process is sent a SIGTERM or SIGINT signal
> (either by a ^C on the terminal, or by the kill command) every thread
> executes the signal handler with a negative signal number, and the
> Sys.sigterm is -11 (negative eleven)
> 
> Is it possible to code so that only the main thread recieves a SIGTERM
> signal and not all threads? Is this a Linux pthread or a OCaml runtime
> system issue?
> 
> (I don't master all the subtilities of Linux threads, in particular
> w.r.t signals).

Unfortunately, Linux does not implement the pthread specification
correctly for signal handling. pthread says that only one thread
gets the signal, and the thread is selected among all threads that
do not block the signal explicitly (there is a per-thread blocking
mask in addition to the usual per-process mask).

Linux, however, does not distinguish correctly between processes
and threads. Every thread is actually a process with special
attributes, and thus signals can be directly sent to threads,
as threads have PIDs. Furthermore, threads are members of process
groups.

What happens if you press ^C? sigint is sent to the whole process
group, and this includes all threads individually (which is wrong).
So all threads get this signal. A correct implementation would
deliver the signal only to one of the threads.

What happens if you kill the main (topmost) process? sigterm is 
sent to this process only, and special logic forwards the signal
to one of the subprocesses that implement the threads. But only
to one of the threads, and this is the correct handling according
to the pthread specification.

If you do not set a signal handler for sigterm, all threads are
terminated. This is again the right behaviour.

I am a bit confused that you say that every thread gets such a
sigterm. Are you sure that you do not mix this case up with the
two other mentioned situations?

There seems to be no real solution for controlling signal handling
in mt programs in O'Caml. There is no function that calls
pthread_sigmask to prevent that certain threads get signals.
The description for Thread.wait_signal sounds like that this function
would attract all signals sent to the process, but in reality 
the function waits only for signals that happen to be delivered
to the thread.

What we need is a way to create a thread that does all signal
handling. A simple solution would an argument to Thread.create
indicating whether the new thread receives signals or not,
so it is simple to handle all signals in one thread:

------------------------------------------------------------------
let f_signal lock =
  (* Wait until the game is over, and handle signals in the meantime *)
  Mutex.lock lock
;;

let lock_signal = Mutex.create() in
Mutex.lock lock_signal;

(* Creating threads: *)
let t1 = Thread.create ~signals:false f1 () in
...
let tn = Thread.create ~signals:false fN () in
let ts = Thread.cretae ~signals:true f_signal lock_signal in

(* Waiting for shutdown: *)
Thread.join t1;
...
Thread.join tn;

(* Stopping ts manually: *)
Mutex.unlock lock_signal;
Thread.joind ts;
------------------------------------------------------------------

I think this is already enough to solve the usual signal problems.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners