caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Basile STARYNKEVITCH <basile@starynkevitch.net>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] SIGTERM signal in multithreaded application
Date: 14 Feb 2003 16:23:02 +0100	[thread overview]
Message-ID: <1045236182.970.111.camel@ice> (raw)
In-Reply-To: <15948.5589.540342.961807@hector.lesours>

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


      reply	other threads:[~2003-02-14 15:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-13 22:01 Basile STARYNKEVITCH
2003-02-14 15:23 ` Gerd Stolpmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1045236182.970.111.camel@ice \
    --to=info@gerd-stolpmann.de \
    --cc=basile@starynkevitch.net \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).