Messages in this thread | | | From | Richard Henderson <> | Subject | Re: [rfc] posix.4 signals implementation | Date | 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.
autofs_write():
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 place.
smb_request() and smb_trans2_request():
Cancels _all_ SIGPIPE after the operation. This should probably be just like autofs.
nfs_sillyrename_cleanup():
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?
r~
| |