<div class="gmail_quote">On Mon, Oct 25, 2010 at 3:54 AM, Daniel Herring <span dir="ltr"><<a href="mailto:dherring@tentpost.com" target="_blank">dherring@tentpost.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
New APIs like signalfd are moving away from the random-interrupt model of signals towards a more I/O friendly model. See e.g.<br>
<a href="http://lwn.net/Articles/225714/" target="_blank">http://lwn.net/Articles/225714/</a><br><div></div></blockquote><div><br>This is interesting, but as I said it is one of two possible views: requesting for signals at specific points of your program vs. letting those signals happen at any time. An important question is whether an implementation may enforce one model.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">I believe things should be implemented to provide "best effort" signal handling. In other words, blocking behavior is to be discouraged, threads should have a way to handle soft interrupts, etc. Maybe there should be one master thread that handles signals and uses ptrace to cleanly interrupt the other threads.</blockquote>
<div><br>We currently have one such master thread that gets _most_ signals. For instance, this thread processes SIGINT (Ctrl-C), but then, in order to allow interrupting a different thread it has to issue a signal to that thread (back to arbitrary interruption).<br>
<br>AFA ECL is concerned, life would be much easier if we could assume that the code in a thread will never be interrupted except in these situations:</div><div><br></div><div>* During I/O, the functions will stop and return when a signal arrives.</div>
<div>* At specific places where checks for pending signals are determined (+)</div><div>* When user tells ECL to wait for signals.</div><div>* As last resort measures: when a SIGSEGV/SIGBUS or during thread cancellation.</div>
<div><br></div><div>This last case would be the only situation in which one would be allowed to exit the signal handler through non-local jump constructs. This would allow safe cleanup -- well, not so safe, for the signal may arrive at an inconvenient time.</div>
<div><br></div><div>Cons:</div><div>* Deadlocks and infinite loops would only be resolved through the "last resort" case.</div><div>* Contrary to people's expectations (?)</div><div><br></div><div>Pros:</div>
<div>* Code can be written without constantly thinking about interrupt safety.</div><div>* POSIX compliant code, cooperates well with the libraries and OS.</div><div>* Cheaper and faster, unless we are forced to include pending signal checks everywhere (See (+) above).</div>
<div><br></div><div>The greatest problem would arise with interactive environments that have these arcane expectations. I am thinking for instance about Maxima, where users expect to have the possibility of interrupting computations, or Slime users.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div></div>
Killing threads or processes always has undefined consequences. Incomplete file writes, interprocess mutexes left in the locked state, etc.</blockquote><div><br></div><div>Unexpected interrupts (or signals at arbitrary places) have a similar problem. I really see no difference. I must say that most of calls to C functions are currently protected against interrupts but some can not be protected (those that lock), or they can at the expense of making the code slower (timed locks).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">Never fun stuff, people seem to be happy when they get signal handling to work most of the time.</blockquote>
</div><div><br></div>Indeed it is not fun, also for implementors, but I would like to reach a compromise that is future-proof, easy to use and increases stability.<div><br></div><div>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>
c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>
</div>