Re: [rfc] posix.4 signals implementation

Richard Henderson (
Thu, 15 May 1997 13:52:51 -0500 (CDT)

> Because when e.g. a mount client dies and mountd attempts to write
> to the socket, it receives a SIGPIPE. Both mountd and the user-space nfsd
> both re-read the exports file on SIGHUP, and unfsd also needs SIGALRM
> to clean up its file handle cache occasionally. What is it exactly
> that gives you headaches?

Here's the list of problematic points. I was actually confusing
lockd with smbfs in my previous message.


Wants to cancel any SIGPIPE delivered to current during the
nested write. I'm guessing that it is going to be just as
unpleasant getting the (possible) signal off the queue as it
would be to get the fs not to deliver the signal in the first

smb_request() and smb_trans2_request():

Cancels _all_ SIGPIPE after the operation. This should
probably be just like autofs.


Removes and restores all pending signals, with a note about
the RPC failing if we don't. What, exactly is the problem
here? Dequeueing and requeueing all of the signals is a
nasty solution; depending on the problem it may work to just
set nsigready to zero, as that's what is tested to break out
of loops.

ftape (most of it):

Queer notions of breaking out of indefinite waits only for
KILL, STOP, and INT -- ie clearly broken by design. Someone
want to explain to me wtf?