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

[Sebastian Lackner]

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...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20151104/96b7b269/attachment-0001.html>