Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: longjmp() from nested signal handlers
Message-ID: <1988Apr7.180514.13161@utzoo.uucp>
Organization: U of Toronto Zoology
References: <4548@june.cs.washington.edu> <26739@amdahl.uts.amdahl.com>, <3669@sdcc6.ucsd.EDU>
Date: Thu, 7 Apr 88 18:05:14 GMT

> I thought unix implementers these days use a similar scheme to
> protect sensitive portions of kernel and library function code.

Kernel, yes, library, no.

> I suppose it would be asking to much to require all C implementations
> to do this.  I don't mind enclosing malloc() calls with protect()/unprotect(),
> and I usually have some uninterruptable code of my own next to
> these calls, but I wouldn't want to have to surround every getc(), printf(),
> etc.

The implementors don't want to have to do that either, which is why they
generally don't.

> Anyway, if anyone is still listening, what versions of unix *do not*
> sensitive system code from interrupts?

Essentially all of them shield kernel code, but they do it by postponing
the interrupt, not by dancing around it in software after it happens.
Nobody that I know of makes any real attempt to shield library functions.
For one thing, it can be quite difficult to get all the details right.
For another thing, THIS PROBLEM HAS ALWAYS EXISTED, and programs that
ignore it are broken already.  X3J11 did not see any compelling reason
to tackle the difficult problem of unbreaking them.
-- 
"Noalias must go.  This is           |  Henry Spencer @ U of Toronto Zoology
non-negotiable."  --DMR              | {allegra,ihnp4,decvax,utai}!utzoo!henry