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

[Waldek Hebisch]

Juan Jose Garcia-Ripoll wrote:
> On Tue, Oct 7, 2008 at 12:34 AM, Waldek Hebisch
> <hebisch at math.uni.wroc.pl> wrote:
> > 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.
> 

Maybe this is what you have in mind, but not what you wrote.  My
reading of "harmless loop" is one that does not call non-interruptible
functions.  Under literal reading of your proposal a) (and in the
spirit of www.securecoding.cert.org) such loop would still contain
checks for interrupts -- clearly performance disaster.  OTOH if
check are linited to library calls performace impact may be
negligible -- non-interruptible calls typically are slow anyway.

Of course, if you have non-interruptible 'qsort' and want to pass
arbitrary function as an argument than you need to be careful --
but one can handle also such cases without requireing checks
everywhere (admitedly, in 'qsort' case best solution is to
provide interruptible version).

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl