<div class="gmail_quote">On Tue, Oct 26, 2010 at 5:54 PM, Waldek Hebisch <span dir="ltr"><<a href="mailto:hebisch@math.uni.wroc.pl">hebisch@math.uni.wroc.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">I think it is reasonable to ignore POSIX restrictions.  POSIX is mostly</div>
a C API standard, so it is affected by limitations of C library.<br></blockquote><div><br></div><div>... which is what ECL uses internally! This is not SBCL, and even they do not have everything under control</div><div> </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
And the standard due to political pressure has to accomodate<br>
essentially obsolete systems.  However, AFAIK at the system call<br>
level on most Unix system there is no problem: one may call system<br>
calls from signal handler or longjmp outside.  There may be problem<br>
with locking in the C library, but C libraries are getting better.<br></blockquote><div><br></div><div>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</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So, I think that ECL should look at capabilites provided by popular<br>
system and base on that (possibly declaring that some functionality<br>
is absent on less popular systems).</blockquote><div><br></div><div>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.</div>

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

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