On the silliness of close() giving EDQUOT

[Barry Shein]

>>["I don't mind close returning -1/EINTR and -1/EBADF."]
>>No other close() errors make sense.
>
>So how do you pick up errors on asynchronous writes?  You are never
>going to know about them if close can't return an error here.

Well, someone has to say it...

OS/360/370 interrupted (signal) when there was an I/O error
(SYNAD=handler) of any sort and you could pick apart what happened in
the handler() routine. SYNAD stood for Syndrome Address if I remember
correctly.

The only hard part was knowing where your program was when the error
struck. A typical technique was to use a global integer and just set
it some value to indicate what you were about to do (often called
"phase", as in "phase = SAVEBUFS", you could hide that sort of thing
pretty well in macros.)

They also interrupted on EOF.

This is where all the ON CONDITION stuff in PL/I makes sense, it
basically models the OS/370 internals.

I am tempted at this point to say "if you want MVS, you know where to
find it", but I won't :-)

I've certainly encountered programs which would have been much easier
to debug if I just could have enabled some sort of "interrupt on any
syscall error", set a bunch of handlers in main and let it fly in a
debugger until one struck, and then look back up the stack to see who
did it. These were typically programs managing to pass garbage args to
system calls but not checking for errors, or writing to bad fd's etc.
Unfortunately many programs can go on for quite a while after such an
event so it's hard to figure out where the chaos started.

It would be pretty easy to implement at user-level by just having a
replacement library for the libc syscalls which checked for an error
return and just did a kill(0,SIGUSER1) or similar if something was
wrong.
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs at world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD