Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!ukma!tut.cis.ohio-state.edu!rutgers!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.uucp
Subject: Re: Bidirectional Modem Lines under SunOS 4.0.1
Message-ID: <8178@chinet.chi.il.us>
Date: 9 Apr 89 19:26:57 GMT
References: <160@osc.COM> <743@key.COM> <2209@laidbak.UUCP> <1395@auspex.auspex.com>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 39

In article <1395@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>
>>In the bidirectional setups I've seen this is done with the LCK..tty
>>file.  Getty opens the tty and then *tries* to create the lockfile,
>>cu/uucico creates the lockfile and then opens the tty.  There is still
>>a little time for a dialin user to get hosed here though.
>
>In the bidirectional setup I've seen, namely the SunOS one, "getty"
>knows absolutely nothing about UUCP lock files, which is nice; you don't
>have to change "getty" to have it work with this scheme.  I think most,
>if not all, of the window in the other scheme is closed with the
>two-devices scheme.

With the lockfile approach there is a small window between getty's open
completing and the creation of the lockfile, during which an outgoing
call might also think the line was free.  This could be eliminated if
there were a way for the outgoing caller to detect that carrier was
already up on the line (atomically, of course..) or if a device
could be opened for exclusive use, although that would cause other
problems unless access could be restricted to the process group of
the process that opens it first.

With both approaches, there is still a window where the outgoing
caller has grabbed the line and is preparing to dial when an
inbound call hits the modem.  This would typically be a longer
interval than that required to make the lockfile, so there is
probably little practical advantage to the two-device approach.

However, if RFS networking makes it practical to use devices on
a remote machine the "lockfile containg PID of active process"
method is going to have to be replaced with something more
versatile as well as dropping the assumption that ttys live in /dev.
An "exclusive use" mode where the device could be used by the
opening process or its children would be nice, with open modes
that would either wait till the device becomes available or return
immediately with an appropriate status.  (Hmm.. this is beginning to
sound a lot like file/region locking - does that work with devices?)

Les Mikesell