Yes, sorry. The following lines were only in v1:
--- snip ---
For
https://bugs.winehq.org/show_bug.cgi?id=14697The 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