Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Severe loss of performance due to new signal handling
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-03-20 (10:40)
From: Oliver Bandel <oliver@f...>
Subject: Re: [Caml-list] Severe loss of performance due to new signal handling
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,
> Now, you may wonder why the problem appears mainly with threaded
> programs.  The reason is that programs linked with the Thread library,
> even if they do not create threads, check for signals much more
> often, because they enter and leave blocking sections more often.  In
> your example, each call to "print_char" needs to lock and unlock the
> stdout channel, causing two signal polls each time.

Is this really necessary? Doing a write to stdout with
locking... if not explicitly wanted?!

> So, it's time to go back to the drawing board.  Fortunately, it
> appears that reliable polling of signals is possible without atomic
> processor instructions.  Expect a fix in 3.09.2 at the latest, and
> probably within a couple of weeks in the CVS.

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.

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).