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@winehq.org>:
Sebastian Lackner <sebastian@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@winehq.org