Path: utzoo!attcan!uunet!lll-winken!decwrl!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.internals Subject: Re: On the silliness of close() giving EDQUOT Message-ID: Date: 20 Oct 90 16:18:59 GMT References: <15544@hydra.gatech.EDU> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 25 In-Reply-To: gt0178a@prism.gatech.EDU's message of 20 Oct 90 10:03:05 GMT From: gt0178a@prism.gatech.EDU (Jim Burns) >in article , bzs@world.std.com (Barry Shein) says: > >> 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. > >> The only hard part was knowing where your program was when the error >> struck. > >And what do you do if the I/O is done as the result of a close? And worse, >if the close is a result of exit processing, and the process doesn't exist >anymore to get the interrupt? Without timely notification, it's hard to >recover. Uh, we're going around in circles here. The assumptions in that thread was that none of what you mention was the case. Obviously if you care about errors you better do your own close() and not leave it to the process rundown (but there's no reason that can't interrupt also.) -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD