<div dir="ltr"><div class="gmail_extra">I personally think its nice that USR1 signals do not crash the application.</div><div class="gmail_extra">Other programs also use it for reloading the configuration, for example.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If performance is a concern, we could also inline wine_server_call here,</div><div class="gmail_extra">then the number of pthread_setmask calls would stay approximately</div><div class="gmail_extra">the same as before. Would that also be an option?</div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-04 14:20 GMT+01:00 Alexandre Julliard <span dir="ltr"><<a href="mailto:julliard@winehq.org" target="_blank">julliard@winehq.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sebastian Lackner <<a href="mailto:purefan@fds-team.de">purefan@fds-team.de</a>> writes:<br>
<br>
> Yes, sorry. The following lines were only in v1:<br>
><br>
> --- snip ---<br>
> For <a href="https://bugs.winehq.org/show_bug.cgi?id=14697" rel="noreferrer" target="_blank">https://bugs.winehq.org/show_bug.cgi?id=14697</a><br>
><br>
> The only disadvantage I'm aware of is that it increases the stack<br>
> usage<br>
> on the signal stack by sizeof(sigset_t) bytes.<br>
> --- snip ---<br>
><br>
> Imho blocking USR1 on the server side is not a good solution, because:<br>
> * If a user somehow sends a USR1 signal manually, it would still<br>
> trigger the bug<br>
<br>
Sure, they could also send SIGSEGV and crash the app. That's not a<br>
interesting case.<br>
<br>
> * We need code to keep track of outstanding APC results in the<br>
> wineserver, and then resend USR1 after all system APCs are finished.<br>
> This could easily get out of sync. Also, in server_select() we do not<br>
> know if we're just in the signal handler, which would be necessary to<br>
> know if an additional USR1 signal is required.<br>
<br>
It doesn't seem that hard to me, and it would certainly be better than<br>
masking/unmasking signals several times in a heavily used request, for<br>
the sake of an extremely unlikely event.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Alexandre Julliard<br>
<a href="mailto:julliard@winehq.org">julliard@winehq.org</a><br>
</font></span></blockquote></div><br></div></div>