[Ecls-list] Revisiting locks and signals

[Daniel Herring]

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/

On Sun, 24 Oct 2010, Juan Jose Garcia-Ripoll wrote:

> Beware, the following is a collection of confused ideas that pop up every few months. They all concern the way Lisp deals with interrupts and thread cancellation.
> Some background. Following SBCL we have fully supported process-kill and process-interrupt using signal handlers. However POSIX demands various things from a signal handler. One is that it should do very little. It is not allowed to
> call almost any function:    http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
> Currently we do not follow this document. When a signal is delivered to a thread one of three things happen
>   1* the signal is queued (forces periodic checks for interrupts)
>   2* control is automatically transferred to an outer error handler (longjmp)
>   3* a lisp error handler is executed from the signal handler
> The last two are obviously non-POSIX compliant.
> 
> For me there is no satisfactory solution so far. A possible extension we tried once is
>   3b* suspend the thread and execute the error handler in a separate thread
> 
> However this still does not solve an important problem: how do we handle functions that lock a thread and for which it is not safe to use signals. I am currently thinking of mp:get-lock, but there are a variety of other functions, C
> or Lisp, external or internal. These are functions that contradict user's expectations:
>   * It is not safe to interrupt them
>   * Yet they may cause a thread to run forever.
> 
> I believe all these problems arise from Common Lisp's users expectations, for which the language should provide the flexibility of an interpreted environment, and also in the implementations themselves, for which the multithreading
> API is in many cases still rooted on preemptive multithreading paradigms. However, in many other programming environments (Java, Python, C, ...) thread cancellation and interrupts either have been strongly deprecated, very much
> restricted or simply do not exist.

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.


> My question is whether it should be possible to live in a Lisp implementation that has no interrupts, allows suspending a thread, allows queueing signals between threads, explicit checks for the presence of those signals and
> finally, as a last resort, killing a thread (pthread_cancel), but knowing that this may or may not leave the implementation in a sane status. Ctrl-C would still work, in a sense, as it does now: it spawns a new thread from which we
> may operate with the environment, performing the previous tasks. It would also do its job, sometimes, as when the implementation awaits input: in that case sending a Unix signal stops the I/O routine safely.
> 
> I also welcome whatever feedback you may have regarding these problems.

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

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

- Daniel