fletcher@cs.utexas.edu (Fletcher Mattox) (08/14/89)
Why are these two signals handled in catch() even when IGN_SIGS is turned on? if (ison(glob_flags, IGN_SIGS) && sig != SIGTERM && sig != SIGHUP) return; What happens if a SIGHUP arrives during copyback() while signals are supposed to be ignored? Consider: 1. User types 'quit'. 2. copyback() turns on IGN_SIGS and begins to write the folder. (This can take many seconds with a large folder on a busy NFS server). 3. Before copyback() can finish, user shuts down his window manager, or his modem drops DTR, or ... 4. Mush catches the resultant signal and eventually exits. 5. copyback() never finishes and user's folder is corrupt. This has happened enough times around here that I'll probably either add a new global flag, REALLY_IGN_SIGS, or change the above fragment to: if (ison(glob_flags, IGN_SIGS)) return; Can something equivalent be added to the mush distribution? Thanks Fletcher
argv%eureka@Sun.COM (Dan Heller) (08/16/89)
In article <6701@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: > Why are these two signals handled in catch() even when IGN_SIGS is > turned on? > if (ison(glob_flags, IGN_SIGS) && sig != SIGTERM && sig != SIGHUP) > return; because IGN_SIGS doesn't really ignore all signals. It ignores keyboard generated signals like ^C and ^\ (sigint and sigquit). catch() may still be called in the event of sighup -- in which case it is important to look at IGN_SIGS. (I'm sure you know this, but this is for the benefit of those who don't) > What happens if a SIGHUP arrives during copyback() while signals > are supposed to be ignored? The copyback is (unfortunately) terminated, but you're saved by the fact that the tempfile is not unlinked. You haven't lost any mail in such case. It's undefined as to what it "should" do, but what it does now is probably not entirely the best thing. It "should" either reinstate the original folder or finish the copyback. You'd think that "finish the copyback" is the right thing, but since you can't interrupt using ^C, et al. and you might want to anyway (because of disk overuse or just a plain old mistake you don't want to lose mail), you could intentionally drop your line or send the program a sighup from the shell. Granted, there are better ways to do this.. :-) > Can something equivalent be added to the mush distribution? something will be done about it. Let me speak with my staff :-) dan <island!argv@sun.com> ----- My postings reflect my opinion only -- not the opinion of any company.