Date: Thu, 17 Dec 1998 15:03:48 +0100 From: Eivind Eklund <eivind@yes.no> To: David G Andersen <danderse@cs.utah.edu>, Alfred Perlstein <bright@hotjobs.com> Cc: karl@Denninger.Net, hackers@FreeBSD.ORG Subject: Re: yup, found it (NFS) Message-ID: <19981217150348.V68793@follo.net> In-Reply-To: <199812170644.XAA03482@lal.cs.utah.edu>; from David G Andersen on Wed, Dec 16, 1998 at 11:44:57PM -0700 References: <Pine.BSF.4.05.9812170116200.378-100000@bright.fx.genx.net> <199812170644.XAA03482@lal.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 16, 1998 at 11:44:57PM -0700, David G Andersen wrote: > Lo and behold, Alfred Perlstein once said: > > as an interrupt) is sent to a process waiting for an NFS server, > > the corresponding I/O system call returns with a transient error. > > (*1) Normally, the process is terminated by the signal.(*2) > > Right. This is simply having the system call return EINTR, one of the > options I duscuss. However, it's not clear to me that this is the best > option when the action was triggered by a close() on a file descriptor. > Certainly, if it happens during a write, most processes know how to cope > with it -- and the kernel does the right thing, returning EINTR. However, > when flushing a dirty block during a close, and you get an intr, what do > you expect to do? Retry the close(), or wait for program termination. Any daemon should be careful about the return value from close(0. Or you could of course do something totally vile like this: Have the kernel fork the process. Have one of them continue the close(), screw the file-descriptor in the other one and return OK. When the sleep is over, finish the close and suicide. In _all_ cases you should allow SIGKILL to actually kill the process _somehow_. Screw dirty blocks, I want to be able to kill processes even if some stupid server in a locked room over there is dead. If I didn't want to be able to make my system behave, I'd be running NT. Eivind, who expect to be flamed over that one even though he _did_ call it totally vile. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981217150348.V68793>