gill (07/16/82)
Another way to lower DTR on interrupted open calls to DZ lines is to close the file descriptor UNIX associates with the uncompleted open. Since the aborted open returned -1, the only way to find out what this file descritor was is to predict it beforehand. A simple program illustrates the hack: #include <signal.h> catch() { } main() { int fd,phantom; printf ("Next fd = %d\n",phantom = nextfd()); signal (SIGALRM,catch); alarm (2); printf ("Open on cul1 returned %d.\n",open ("/dev/cul1",2)); #ifdef KLUDGE close (phantom); #endif printf ("Next fd = %d\n",phantom = nextfd()); pause(); } nextfd() /* Return the number of the next file desciptor assuming no closes happen until the next open */ { int phantom; close (phantom = open("/dev/null",0)); return (phantom); } If KLUDGE is defined, then you get the same file descriptor both before and after the aborted open (which returns -1). DTR is lowered by the close(phantom). If KLUDGE is undefined, you get two sequential descriptors, and the DTR lead isn't lowered until you stop the process (i.e. let the system do the close). Well, this is conceptually simpler than my fix, which involved forking off an open prober, but it really violates the abstraction of file descriptors being numbers passed to and returned by system calls. It's the close/dup assumption taken to the extreme. If the ordinary UNIX interface is call/return by value, the use of a predicted file descriptor which you can't even verify (as you can with dup) is "call/return by intuition." Yuch. Thanx to Peter Honeyman for pointing this alternative out (it's actually the method used by the research folks in their dialout() routine). Gill Pratt ...alice!rabbit!physics!gill or ...gill@mc