This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Can you undo change in sig_dispatch_pending() ?


On Tue, Oct 30, 2007 at 04:35:05PM +0200, Oleg Volkov wrote:
>New signals, which need to be dispatched, are added to the end of queue of
>pending signals, implemented as linked list, which is stored in variable
>`sigq'. A pointer to the first pending signal can be obtained by expression
>`sigq.start.next'. As we can see, in version 1.5.19-4 there was a check:
>if queue of pending signals is empty, then return immediately; otherwise
>function sig_send() with special argument is called, by means of which
>time-consuming immediate signal dispatching is triggered. Why this check
>was removed?
>
>There are lines in ChangeLog:
>
>2006-02-24  Christopher Faylor  <cgf at timesys dot com>
>
>      * sigproc.cc (sigheld): Define new variable.
>>       (sig_dispatch_pending): Don't check sigq since that's racy.
>        (sig_send): Set sigheld flag if __SIGHOLD is specified, reset it if
>        __SIGNOHOLD is specified.  Ignore flush signals if we're holding
>        signals.
>
>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.

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.  Have you tried that?

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]