[Ecls-list] Revisiting locks and signals

[Juan Jose Garcia-Ripoll]

On Tue, Oct 26, 2010 at 5:54 PM, Waldek Hebisch <hebisch at math.uni.wroc.pl>wrote:

> I think it is reasonable to ignore POSIX restrictions.  POSIX is mostly
> a C API standard, so it is affected by limitations of C library.
>

... which is what ECL uses internally! This is not SBCL, and even they do
not have everything under control


> And the standard due to political pressure has to accomodate
> essentially obsolete systems.  However, AFAIK at the system call
> level on most Unix system there is no problem: one may call system
> calls from signal handler or longjmp outside.  There may be problem
> with locking in the C library, but C libraries are getting better.
>

I do not believe this. C libraries get better in terms of multithreading
support and locking between threads, but they do not support async-signal
safety. GNU libc explicitely speaks against it as do  other vendors that
follow POSIX. We do have to take this seriously

So, I think that ECL should look at capabilites provided by popular
> system and base on that (possibly declaring that some functionality
> is absent on less popular systems).


The problem with signals and interrupts is that the behaviour we would like
(arbitrary interruptions are ok, arbitrary code is, too) is not something
*provided*. Something provided is a behavior that one can rely on, not the
current status of things that may or may not work.

Look at it from a reasonable point of view: it is impossible to write code
that is async-signal-safe and allows arbitrary interruptions at
unpredictable times. This may happen in the middle of a slot write or read,
or while modifying a list, or while reading from a file (as in FILE) which
is left in a locked state (and thus the signal handler code can not use the
file), etc, etc.

The only way to avoid those problems within the optimistic way of coding is
to switch on and off interrupts all the time, but if one looks carefully at
the code, then the places where the ON status is feasible is a very small
fraction of the code.

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/20101029/181d8900/attachment.html>