ntdll: Block signals while executing system APCs. (v2)
sebastian at fds-team.de
Wed Nov 4 07:33:32 CST 2015
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 at winehq.org>:
> Sebastian Lackner <purefan at 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 at winehq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wine-devel