[Ecls-list] More thoughts on signals, stack overflows, etc

[Juan Jose Garcia-Ripoll]

On Tue, Oct 7, 2008 at 12:34 AM, Waldek Hebisch
<hebisch at math.uni.wroc.pl> wrote:
> I think we should look at real-world issues: why standards forbid
> longjmp?

Note that not all standards forbid longjmp. It depends on which one
you read and the date it was published. Besides this, when you go to
actual the C library manuals (IBM, Sun, GLIBC many do explicitely
mention the possibility of using longjmp(), if only stating that the
user should take care of her own data structures
http://www.gnu.org/software/libtool/manual/libc/Longjmp-in-Handler.html

> Now this example shows that separate thread really does not solve
> any problem: critical data structures typically are shared by
> all threads, so if one thread messes them up the other threads
> will stop working too.

This is more to the point: not all C code is reentrant and the
standards impose no burden on the C library to be.

> OTOH this suggests another tactic: wrap each problematic call.  The
> wrapper will set thread local "in uniteruptible call" flag.  Signal
> handler seeing this flag will just append relevant data to pending
> interrupts list and return normally.

This is the strategy I mentioned as a) The problem with this is that
it poses a burden on both the compiler and the runtime, forcing checks
for pending interrupts everywhere, including loops that may be
harmless. I think that I have found some efficient solution for this,
though: see my next message.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28009 (Spain)
http://juanjose.garciaripoll.googlepages.com