Re: Can you undo change in sig_dispatch_pending() ?

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Wed, Oct 31, 2007 at 05:06:17PM +0200, Oleg Volkov wrote:
>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.
>
>I have explained, why assumption about racing condition is wrong. My main
>argument was: reading and updating a pointer (that is, variable
>`sigq.start.next') is performed atomically by CPU, since pointers are of
>size `int', and read and assignment to `int' are atomic.

Of course updating a single variable could conceivably not be racy.  We
are talking about a separate thread which does all sorts of things to
the variable, however, like preparing to update it, for instance.  It really
is possible that the "sig" thread can be in the process of updating sigq
while sig_dispatch_pending is in the process of testing it.

>Note, that check of condition `!sigq.start.next' will never cause access
>violation, since this expression does not contain references by pointers
>(however, a whole expression `sigq.start.next' is the pointer, but there is
>no access by its address, it's only checked for being zero/non-zero).
>
>> 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?
>
>I suppose, that the purpose of invocation of sig_dispatch_pending() from
>readv() and writev() is to dispatch signals as many as possible before
>Win32 call, which actually performes input/output, since this call can take
>much time, and no signals can be dispatched during it.

I don't know if you know this or not but I wrote this code so there is
no reason to explain it to me.

If you have tests for this then you can either try removing the
sig_dispatch_pending entirely and see how that works or you can generate
data showing how often the sigq.start.next test is triggered and report
the results here.

cgf