This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Can you undo change in sig_dispatch_pending() ?
On Wed, 31 Oct 2007, Christopher Faylor wrote:
> On Tue, Oct 30, 2007 at 04:35:05PM +0200, Oleg Volkov wrote:
> >So it was considered that check of `sigq.start.next' introduces racing
> >condition, and this affects Cygwin stability. But this suggestion is wrong.
>
> No. It is not.
Could you please elaborate?
It is correct that this introduces a race condition. However, delivering
signals in this way is inherently racy, and sig_dispatch_pending is a best
effort function. Thus, the performance penalty does not justify the
removal of this particular race condition.
> However, if you think that this check can be put back then it seems like
> the next logical step is to remove the sig_dispatch_pending from readv
> and writev.
That doesn't seem logical to me. We still need that functionality, but
there is a race between calling sig_dispatch_pending, when signals arrive,
and progressing further in the Cygwin syscall code down to the blocking
Windows call anyway. How does the tiny sigq.start.next race removal
matter when there is a race just calling the function?
>From how-signals-work.txt:
(For pending signals, the theory is that the signal handler thread will
be forced to be rerun by having some strategic cygwin function call
sig_send with a __SIGFLUSH argument. This causes the signal handler to
rescan the signal array looking for pending signals.)
So, sig_dispatch_pending's purpose is to flush pending signals. If there
are no signals pending in the sigq.start.next at the time of
sig_dispatch_pending's call, then there is no reason to wake the signal
handling thread. The only thing this prevents is the case when a signal
becomes pending between the check of sigq.start.next and when the signal
handling thread would have awoken to check same. Since a signal could
just as easily go pending just after the call to sig_dispatch_pending
returns, what is the gain?
> Have you tried that?
No, because I do not think that would be correct. Note that something
eventually still needs to flush those pending signals, but closing this
tiny window when there are several other big ones doesn't seem necessary.
--
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...