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

[Xavier Leroy <Xavier.Leroy@inria.fr>]

 > The problem is the following: [...] 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.

Actually, the problematic code in 3.08 is:

   tmp <- flag;
   (*)
   flag <- 0;
   if (tmp) { process the signal; }

and indeed a signal can be lost (never processed) if it occurs at (*).

The solution I have in mind is to implement exactly the pseudocode you
give above.  If a signal occurs at (*), it is not lost (the signal
handler function will be called just afterwards!), just conflated with
a previous occurrence of that signal, but this is fair game: POSIX
signals have the same behaviour.  (Yes, I'm ignoring the queueing
behaviour of realtime POSIX signals.)

Note however that in 3.09 and in my proposed fix, there is one flag
per signal, which still improves over 3.08 (which had only one shared
flag) and ensures that two occurrences of different signals are not
conflated, again as per POSIX.

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

That would be plan C, plan B being making the check even more efficient.
I'd rather not introduce timer signals if at all possible, though,
since these mess up many function calls.

- Xavier Leroy