<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I do not think that this is a valid reason. What that paragraph is<br>
trying to tell is that you either have to avoid calling anything that<br>
modifies global state and may cause trouble or block signals in sections<br>
that do the same but in the normal program context. Either way that<br>
effectively makes sure that such code is never run concurently.<br>
<br>
For example calling malloc()/free() modifies locks and data structures<br>
in libc, it's not safe to be called from signal handler and can easily<br>
cause deadlocks and corruptions. Technically you can avoid that either<br>
by not calling malloc()/free() from a signal handler, or by disabling<br>
signal handlers before you call malloc()/free() or anything that may<br>
possibly call malloc()/free() in the rest of the program.<br>
<br>
In this case the signal handler is as simple as it gets, it only sets a<br>
global flag that is checked in the while () loop that reforks. And the<br>
only important thing we do there is the fork(). However fork() cannot be<br>
interrupted by a signal and return EINTR so it cannot even fail. It<br>
would probably made some sense if we wanted to setup different signal<br>
handlers in the child and avoid getting signals before we do so, but<br>
that's not the case here either.<br>
<br>
So either this is a leftover code that was there to protect something<br>
that has been removed long in the past, or copy&pasted code from a<br>
different test that acutally made use of that. At least I do not see any<br>
other reason to have it there.<br>
<br>
-- <br>
Cyril Hrubis<br>
<a href="mailto:chrubis@suse.cz" target="_blank">chrubis@suse.cz</a></blockquote><div><br></div><div>Thanks for the explanation!  That makes sense.</div><div><br></div><div>Thanks,</div><div>Edward </div></div></div>