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