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

[Sebastian Lackner]

Well, you are the development branch maintainer, but for me a
code which fails only in 0.00001% of all cases is still incorrect. ;)

However, I also think that your idea to use a flag/counter in the wineserver
cannot really work. Lets assume the following code sequence:

* client starts the wineserver call, and calls pthread_setmask()
* server sends a SIGUSR1, because no outstading system APCs yet
* client writes the request
* server assumes that it is safe to dequeue the system APC now, only
further USR1 signals are blocked
* client waits for the reply
* client restores signal mask, and receives the SIGUSR1 during the system
APC

To fix that remaining race, you would have to check somehow, if the send
SIGUSR1
has already arrived in the meantime. I think it only gets more ugly when
going
in this direction. :/

2015-11-04 14:49 GMT+01:00 Alexandre Julliard <julliard at winehq.org>:

> Sebastian Lackner <sebastian at fds-team.de> writes:
>
> > I personally think its nice that USR1 signals do not crash the
> > application.
> > Other programs also use it for reloading the configuration, for
> > example.
>
> You say that it's so hard to trigger the race that you can't do it in a
> test program even trying a thousand times, but you are concerned that
> users will trigger it by accident, doing something that nobody ever
> does?  Come on...
>
> > 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?
>
> It's quite ugly. It would need a convincing case that it can't be done
> any other way, and that it's affecting enough users to be worth it (with
> all due respect to Anastasius, it's not worth uglifying the code just
> for his specific use case).
>
> --
> Alexandre Julliard
> julliard at winehq.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20151104/fc4e12ee/attachment.html>