hitt@Neon.Stanford.EDU (Daniel Hitt) (12/01/90)
How can a program determine which process owns the serial port? Is there a system call which will return the pid of the owning process? If not that, is there some table that can be read which records who owns what resources? dan
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (12/05/90)
In article <1990Nov30.185944.12618@Neon.Stanford.EDU>, hitt@Neon.Stanford.EDU (Daniel Hitt) writes: > How can a program determine which process owns the serial port? Is > there a system call which will return the pid of the owning process? > If not that, is there some table that can be read which records who > owns what resources? It's not clear what you mean here. In what sense can a process "own" the serial port? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu (Or am I just exposing my ignorance of the NeXT? :-)
hitt@Neon.Stanford.EDU (Daniel Hitt) (12/06/90)
In article <1990Dec5.130712.18403@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: > >It's not clear what you mean here. In what sense can a process "own" >the serial port? 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.) dan
scott@NIC.GAC.EDU (Scott Hess) (12/07/90)
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 . . .