117 lines
4.2 KiB
Plaintext
117 lines
4.2 KiB
Plaintext
|
|
|
|
Bill Claghorn of Diaquest (claghorn@crl.com) was using tserialio to
|
|
write his app.
|
|
|
|
He noticed that if he system()ed off a sub-process (apanel or vcp for
|
|
example) while a TSport was open, then he closed the TSport, subsequent
|
|
attempt to open the same serial port would fail with EBUSY.
|
|
|
|
Basically the fork() and exec() done by system() caused the ts file
|
|
descriptor to get dup'ed, and then we only called tsClosePort() from
|
|
one process, so the driver thinks the serial port never gets closed.
|
|
|
|
Here's the cause and a solution.
|
|
|
|
|
|
From cpirazzi Tue Sep 23 20:43:59 1997
|
|
From: cpirazzi@cp (Chris Pirazzi)
|
|
Date: Tue, 23 Sep 1997 20:43:59 -0700
|
|
In-Reply-To: Bill Claghorn <claghorn@crl.com>
|
|
"tserialio failure" (Sep 22, 6:06pm)
|
|
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
|
|
To: Bill Claghorn <claghorn@crl.com>
|
|
Subject: Re: tserialio failure
|
|
Status: OR
|
|
|
|
hmm,
|
|
|
|
when you open a TSport (or an ALport, or a VLPath, or a ...), the
|
|
library opens up an fd to communicate with some driver. when you
|
|
fork, those fds are still open. when you exec, those fds are still
|
|
open unless the file descriptor has the kludgy irix-specific F_CLOEXEC
|
|
flag of fcntl(2) set. maybe I need to set that flag from
|
|
libtserialio.
|
|
|
|
I just checked and we don't use CLOEXEC from the AL. I doubt we use
|
|
it from the VL either. but in those cases the fd being open does not
|
|
lock out subsequent openers quite so much (it DOES lock out openers
|
|
after a driver-specific number of opens, probably about 16. this would
|
|
cause alOpenPort and vlCreatePath to fail).
|
|
|
|
hmm, let me think about the ramficiations of CLOEXEC.
|
|
|
|
in the meantime you can work around this during your development
|
|
with
|
|
|
|
fcntl(tsGetFD(port), F_GETFD, &flags);
|
|
flags |= FD_CLOEXEC;
|
|
fcntl(tsGetFD(port), F_SETFD, &flags);
|
|
|
|
make sure I've given you some more long-term answer on this before you
|
|
ship it. this may not be a good thing to have when you're porting your
|
|
app to other machines.
|
|
|
|
- Chris Pirazzi
|
|
|
|
|
|
|
|
From cpirazzi Tue Sep 23 20:55:01 1997
|
|
From: cpirazzi@cp (Chris Pirazzi)
|
|
Date: Tue, 23 Sep 1997 20:55:01 -0700
|
|
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
|
|
To: staff@mindless
|
|
Subject: dmedia libs and FD_CLOEXEC
|
|
Cc: alai, sporter, bryanj, wtw
|
|
Status: OR
|
|
|
|
|
|
this is a library implementation issue that I know has come up before,
|
|
but I'm not sure if anyone who dealt with it is still working for SGI
|
|
and not on sabbatical, but here goes:
|
|
|
|
I got a customer complaint about tserialio like this:
|
|
|
|
:-> I am having a failure in tserialio.
|
|
:->
|
|
:-> If I open tserialio, fork my application to exec apanel,
|
|
:-> and then close the tserialio port and my application without closing
|
|
:-> apanel,
|
|
:-> then the next time I open my application, tserialio says that the
|
|
:-> tserialio port is busy. It remains busy until the apanel is clised.
|
|
|
|
this issue also applies to AL, VL, dmIC, and several other libraries.
|
|
|
|
the issue is that our libraries open up file descriptors for various
|
|
purposes in their handle open routines. when the app forks, those
|
|
file descriptors get duped. when the app execs, those files
|
|
descriptors remain open, unless they were opened with the kludgy
|
|
irix-specific FD_CLOEXEC flag of fcntl(2):
|
|
|
|
F_GETFD Get the file descriptor flags associated with the descriptor
|
|
fildes. If the FD_CLOEXEC flag is 0 the descriptor will remain
|
|
open across exec, otherwise the descriptor will be closed upon
|
|
execution of exec.
|
|
|
|
the end result is that after a library- and device-specific number of
|
|
fork/execs (as low as 1), any attempt to open up another instance of
|
|
that device by ANY PROCESS ON THE SYSTEM will fail. this is because
|
|
our drivers have hard upper limits on the number of times they can
|
|
be opened in various directions.
|
|
|
|
in the case of tserialio, this was 1, because a serial port is an
|
|
exclusive-open device for output. for VL and dmIC, the number is
|
|
probably more like 16.
|
|
|
|
the answer in the case of this problem is obviously not to crank up
|
|
the driver-specific limits! in this situation, the app only intends
|
|
to open the resource once but accidentlly keeps it open for the
|
|
lifetime of N>1 programs.
|
|
|
|
none of our libraries use FD_CLOEXEC as far as I know.
|
|
|
|
does anyone know of gotchas we'd hit if our libraries did use FD_CLOEXEC?
|
|
(or at least tserialio)?
|
|
|
|
- Chris Pirazzi
|