honey@allegra.UUCP (09/02/83)
the lock aging mechanism is not worth improving. in "the uucp of the future" (redman/nowitz/honeyman and now bellovin) we exploit the USG feature that allows one to send signal 0 to a process to determine whether the process lives. in UCB unix, this requires hacking the kernel (in a trivial and obvious way). (i giggle at the thought of hacking kernel to support uucp.) bill joy once indicated that signal(0) would be supported in 4.2; it is not supported in 4.1c. peter
chris@umcp-cs.UUCP (09/02/83)
The same thing happens when transferring large files. The LCK files
won't get touched by UUCP *during* the transfer -- only afterwards.
So if the copy takes 7 hours (we have been known to send *large* files
at 300 baud!) you can guess what happens...
Fortunately, we only had one dial-out back then, and since it's exclusive
use, we couldn't get extra uucicos running (transferring the same file!).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@UDel-Relayperl@rdin.UUCP (Robert Perlberg) (09/02/83)
Uucp will not honor LCK. files that are more than 1.5 hours old. This is well documented and I think it's a good idea, but it gives me one big headache: cu does not touch the LCK. file after it creates it so if you are using cu for more than 1.5 hours and a uucico starts up -- BOOM! Why hasn't someone at Bell or Berkeley discovered this and corrected it? It's in every version of UNIX I've used. Remember, we don't all have source licenses and many of us have to rely on fixes from our suppliers. And while they're at it, they might want to improve it. Since orphaned LCK. files are such a problem, they should be touched more often. As long as every program in the system that deals with LCK. files assumes the same standard for how old a LCK. file can be, you could use anything, like five or ten minutes. This would improve the delay time when someone tries to use a line that has an orphaned LCK. file. Robert Perlberg Resource Dynamics Inc. New York philabs!rdin!perl
dave@utcsrgv.UUCP (Dave Sherman) (09/12/83)
Alan Watt has a point about exclusive use having to be set after the
file is open, causing a race condition.
Maybe this is time to consider adding options to open() which can
be OR'ed into the higher bits of the second argument. Exclusive-use
is an obvious candidate. Presumably, it wouldn't be hard to change
stdio to add some letter (say, 'e') to the fopen call (e.g.,
fopen(iop, "we")), if necessary. Then again, I can see this leading
to a horribly complex system, with a lot of overlap between open
and ioctl, once it extends beyond exclusive-use.
Incidentally, not all drivers implement TIOCEXCL. (Yes, Virginia,
exclusive-use is implemented in the *driver*.) I have had to add
a check for ISOPEN&XCLUDE to both the kl.c (DLV-11J) and dz.c (DZV-11)
drivers on the lsuc 11/23 running v7.
Dave Sherman
The Law Society of Upper Canada
Toronto
--
{cornell,decvax,floyd,ihnp4,linus,utzoo,uw-beaver,watmath}!utcsrgv!lsuc!dave