Browse thread
Severe loss of performance due to new signal handling
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2006-03-20 (15:56) |
From: | Xavier Leroy <Xavier.Leroy@i...> |
Subject: | Re: [Caml-list] Severe loss of performance due to new signal handling |
> 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