I personally think its nice that USR1 signals do not crash the application. Other programs also use it for reloading the configuration, for example.
If performance is a concern, we could also inline wine_server_call here, then the number of pthread_setmask calls would stay approximately the same as before. Would that also be an option?
2015-11-04 14:20 GMT+01:00 Alexandre Julliard julliard@winehq.org:
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