Re: [Caml-list] Severe loss of performance due to new signal handling

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am Montag, den 20.03.2006, 11:39 +0100 schrieb Oliver Bandel:
> On Mon, Mar 20, 2006 at 10:29:49AM +0100, Xavier Leroy wrote:
> > > It seems that changes to signal handling between OCaml 3.08.4 and 3.09.1
> > > can lead to a very significant loss of performance (up to several orders
> > > of magnitude!) in code that uses threads and performs I/O (tested on 
> > Linux).
> > > [...]
> > > Maybe some assembler guru can repeat this result and explain to us
> > > what's going on...
> > 
> > Short explanation: atomic instructions are dog slow.
> > 
> > Longer explanation:
> > 
> > OCaml 3.09 fixed a number of long-standing bugs in signal handling
> > that could cause signals to be "lost" (not acted upon).  The fixes,
> 
> I'm not clear about what your proble is with lost signals,
> but when using signals on Unix/Linux-systems, you can use
> UNIX-API, with sigaction/sigprocmask etc. you can do things well,
> and with the signal-function which C provides things are bad/worse.
> The C-API signal-function signal(3) clears out the signal handler
> after a call to it. In the sigaction/sigprocmask/... functions
> the handler remains installed.

The problem is the following: The O'Caml runtime cannot handle signals
immediately because this would break memory management (e.g. imagine a
signal happens when memory has just been allocated but not initialized).
To get around this the signal handler sets just a flag, and the compiler
emits instructions that regularly check this flag at safe points of
execution (i.e. memory is known to be initialised). These instructions
are now atomic in 3.09. In 3.08, you have basically

if "flag is set" then (
  (*)
  "clear flag";
  "call the signal handler function"
)

If another signal happens at (*) it will be lost.

As you mention sigprocmask: Of course, you can block signals before
checking the flag and allow them again after clearing it, but this would
be even _much_ slower than the solution in 3.09, because sigprocmask
needs a context switch to do its work (it is a kernel function).

I don't know what Xavier has in mind to solve the problem, but I would
think about reducing the frequency of the atomic check.
This could work as follows:

- Revert the check to the 3.08 solution
- Use the alarm clock timer to regularly call a signal_manager
  function at a certain frequency (i.e. the signal flag is set
  at a certain frequency)
- Only the alarm clock timer signal is left unblocked. The
  other signals are normally blocked.
- In signal_manager, it is checked whether there are other
  pending signals, and if so, their functions are called.

Of course, it is again possible that alarm clock signals are lost, but
this is harmless, because it is a repeatedly emitted signal. The other
signals cannot be lost, but their execution is deferred to the next
alarm clock event.

> But if this is what you think about (and how it will be done
> on windows or other systems) I don't know, but maybe this is
> a hint that matters.
> 
> BTW: I saw that in the Unix-module the unix-signalling functions are
>      now included... (the ywere not on older versions of Ocaml).

They have been included for a long time. New is Thread.sigmask.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------