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.<div><div><br></div><div>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:<div>

   <a href="http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html">http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html</a></div><div>Currently we do not follow this document. When a signal is delivered to a thread one of three things happen</div>

<div>  1* the signal is queued (forces periodic checks for interrupts)</div><div>  2* control is automatically transferred to an outer error handler (longjmp)</div><div>  3* a lisp error handler is executed from the signal handler</div>

<div>The last two are obviously non-POSIX compliant.</div><div><br></div><div>For me there is no satisfactory solution so far. A possible extension we tried once is</div><div>  3b* suspend the thread and execute the error handler in a separate thread</div>

<div><br></div><div>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:</div>

<div>  * It is not safe to interrupt them</div><div>  * Yet they may cause a thread to run forever.</div><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>I also welcome whatever feedback you may have regarding these problems.</div><div><br></div><div>Juanjo</div><div><br></div><div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br>

<a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a></div></div></div>