On Tue, Oct 26, 2010 at 5:54 PM, Waldek Hebisch <firstname.lastname@example.org>
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.