Sebastian Lackner <purefan@fds-team.de> writes:

> 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

Sure, they could also send SIGSEGV and crash the app. That's not a
interesting case.

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

It doesn't seem that hard to me, and it would certainly be better than
masking/unmasking signals several times in a heavily used request, for
the sake of an extremely unlikely event.

--
Alexandre Julliard
julliard@winehq.org