🚀 go-pugleaf

In article <5505@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes:
} If you use DOT_LOCK, mush doesn't ignore signals in copyback() until
} *after* the folder has been truncated.  This can be Bad News if a
} signal is received while trying to write back your spool mailbox.
} Especially if disk io is a little sluggish, say because of an NFS retry
} or two ...

The fix for this (as best can be made) is twofold.

First, stop special-casing DOT_LOCK for opening with "w+" and just let it
be opened with "r+" and truncated later like everybody else.

Second, turn on IGN_SIGS a little sooner, just before you do the truncation.
We have to wait until after the lock_file() call because the user may want
to interrupt the "waiting to lock" loop, but otherwise there isn't any good
reason not to ignore signals before opening with "w".

} And even after you have turned on IGN_SIGS, doesn't this code in
} catch() defeat it?
} 
}     if (ison(glob_flags, IGN_SIGS) && sig != SIGTERM && sig != SIGHUP)
} 	    return;

Sort of.  TERM and HUP are just being lumped in with other signals that
cannot be caught, like KILL.  An NFS sluggishness shouldn't cause either
of TERM or HUP to be sent.  The trouble with HUP especially is that it
indicates that mush really ought to exit -- it just ought to finish what
it is doing first.  Unfortunately, there isn't a portable way to defer
the HUP signal and catch it later, so mush does the best it can.

When somebody has time for a rewrite, the whole signal-catching mechanism
will get an overhaul along with everything else.  In the meantime, Patch #2
will move the IGN_SIGS to above the truncation.  That should at least take
care of some problems.  Coming soon to a comp.sources.bugs near you.
-- 
Bart Schaefer       "And if you believe that, you'll believe anything."
							-- DangerMouse
CSNET / Internet                schaefer@cse.ogc.edu
UUCP                            ...{sequent,tektronix,verdix}!ogccse!schaefer