[Ecls-list] Revisiting locks and signals

[Juan Jose Garcia-Ripoll]

On Mon, Oct 25, 2010 at 3:54 AM, Daniel Herring <dherring at tentpost.com>wrote:

> New APIs like signalfd are moving away from the random-interrupt model of
> signals towards a more I/O friendly model.  See e.g.
> http://lwn.net/Articles/225714/
>

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.

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.


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).

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:

* During I/O, the functions will stop and return when a signal arrives.
* At specific places where checks for pending signals are determined (+)
* When user tells ECL to wait for signals.
* As last resort measures: when a SIGSEGV/SIGBUS or during thread
cancellation.

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.

Cons:
* Deadlocks and infinite loops would only be resolved through the "last
resort" case.
* Contrary to people's expectations (?)

Pros:
* Code can be written without constantly thinking about interrupt safety.
* POSIX compliant code, cooperates well with the libraries and OS.
* Cheaper and faster, unless we are forced to include pending signal checks
everywhere (See (+) above).

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.

Killing threads or processes always has undefined consequences. Incomplete
> file writes, interprocess mutexes left in the locked state, etc.


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).

Never fun stuff, people seem to be happy when they get signal handling to
> work most of the time.


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.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20101025/df3c9b63/attachment.html>