Fwd: ntdll: Block signals while executing system APCs. (v2)

[Sebastian Lackner]

(Sending a second time, because I accidentally used a mail account not
subscribed to wine-devel)

Yes, sorry. The following lines were only in v1:

--- snip ---
For https://bugs.winehq.org/show_bug.cgi?id=14697

The only disadvantage I'm aware of is that it increases the stack usage
on the signal stack by sizeof(sigset_t) bytes.
--- snip ---

Imho blocking USR1 on the server side is not a good solution, because:
* If a user somehow sends a USR1 signal manually, it would still trigger
the bug
* We need code to keep track of outstanding APC results in the wineserver,
and then resend USR1 after all system APCs are finished. This could easily
get out of sync. Also, in server_select() we do not know if we're just in
the signal handler, which would be necessary to know if an additional USR1
signal is required.

I'm not aware of a good way to write a test case for this, because it
highly depends on the timing. All system APCs are usually finished within a
few clock cycles. The only way to trigger this bug is to interrupt just
while processing the APC, but before sending the result. There is no way to
write a reliable test for that (and running the same test more than
thousand times in a loop doesn't make it better).

Regards,
Sebastian

2015-11-04 13:50 GMT+01:00 Alexandre Julliard <julliard at winehq.org>:

> Sebastian Lackner <sebastian at fds-team.de> writes:
>
> > Changes in v2:
> >   * Do not delete the still valid comment "Return TRUE if a user APC has
> been run.".
> >     I still had this deleted from an earlier version of the patchset,
> where the
> >     return type was changed.
> >
> > If a USR1 suspend signal arrives between dequeing a system APC and
> sending
> > back the result to the wineserver, a deadlock occurs. To avoid this issue
> > this patch blocks all signals in server_select(), except while waiting or
> > processing user APCs.
>
> I'm guessing this is for bug 14697?  It seems to me you could do that on
> the server side, by not suspending the thread while system APCs are
> outstanding. Also a test case demonstrating the bug would be a good
> first step.
>
> --
> Alexandre Julliard
> julliard at winehq.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20151104/46c41ceb/attachment.html>