Re: Can you undo change in sig_dispatch_pending() ?

[Brian Ford <Brian dot Ford at FlightSafety dot com>]

On Wed, 31 Oct 2007, Oleg Volkov wrote:

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

Which is correct.

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

Also correct.

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

Actually, since in most cases some sort of overlapped I/O is used and WFMO
has a signal_arrived event object, they can be dispatched during it.

I think there are two purposes for sig_dispatch_pending: delivery of
pending signals when the signal mask changes, and delivery of signals that
went pending because (form how-signals-work.txt):

To accomplish its task, setup_handler first inspects the target thread's
local storage (_cygtls) structure.  This structure contains information on
any not-yet-handled signals that may have been set up by a previous call
to setup_handler but not yet dispatched in the target thread.  If this
structure seems to be "active", then setup_handler returns, notifying it's
parent via a false value.

When false is returned for a new signal, it is added to the pending list
via sigq.add in wait_sig.  This latter reason is why I believe the call to
sig_dispatch_pending is called by most Cygwin syscalls.

> But the situation, when some signals are left undispatched before that
> Win32 call, can not be prevented completely, since there are many lines of
> code between call to sig_dispatch_pending() and Win32 call. Avoiding
> check of `sigq.start.next' slightly reduces likelihood of a signal to be
> left undispatched at the cost of triple decrease of performance of readv()
> and writev().

Agreed as well.

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...