Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!att!pacbell.com!ucsd!ucbvax!NIC.GAC.EDU!scott
From: scott@NIC.GAC.EDU (Scott Hess)
Newsgroups: comp.sys.next
Subject: Re: determining which process owns the serial port
Message-ID: <9012061631.AA17122@mcs-server.gac.edu>
Date: 6 Dec 90 16:31:48 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 51

In article <1990Dec6.063338.402@Neon.Stanford.EDU> hitt@Neon.Stanford.EDU (Daniel Hitt) writes:
   When you want to use MIDI, for example, you must ``own'' the port.
   For example, you could open a couple of terminal windows and use
   /NextDeveloper/Examples/MidiDriver/playmidifile to start playing
   a midifile, then immediately go to the other window and try to
   execute the same program.  It will say ``port in use, become
   owner first'' or something similar.

   (In fact, if you dig through the documentation, you see that
   to play through midi you must own a port---this may be a software
   port, but still there's a question of how to determine who owns it.
   I'd like to know how to do this determination, from software,
   and probably there's some table somewhere which records the necessary info.)

Hmm.  A question might be if it is talking about the serial port, in
particular, or a more generic port . . . if it was talking about the
serial port, I would expect the wording to be ``device in use,
become owner first'', but maybe I'm full of it.  If you get this
error when attempting to run a midi-using program while another midi-
using program or dsp-using program is running, the error _might_
be the result of non-ownership of a dsp or midi specific port,
and might have nothing at all to do with the serial port.

If it really is the serial port, there isn't any method of determining
ownership.  Multiple processes are perfectly capable of opening up
the serial devices and reading and writing to their heart's content -
with no exclusion.  There are a couple places where you could get
locked out, if you are "nice".  The serial device _could_ be opened
by someone else in exclusive access mode.  The best way to figure
this out would more than likely be to try to open it, then try to
flock(2) it exclusively, and check the errno.  But, many programs
probably ignore that, and since it's just an advisory lock, if
a program doesn't use it, it won't help you at all.

Many programs also use a locking mechanism of creating a file in
the uucp lock directory by calling open(2) with (O_EXCL|O_CREAT).
According to kermit, the file (on the NeXT) is
/usr/spool/uucp/LCK/LCK..cua for /dev/cua.  Again, that might
not mean anything.

You might want to read the documentation on uucp to find out more.
Else, if you want source, grab kermit.  The documentation for kermit
might help, also, because it appears to me to be more extensive
in this regards (serial device locking) than the uucp stuff.

scott hess
scott@gac.edu
Independent NeXT Developer	(Stuart)
GAC Undergrad			(Horrid.  Simply Horrid.  I mean the work!)
<I still speak for nobody>
Tried anarchy, once.  Found it had too many constraints . . .