Given an file descriptor that may or may not be open, what's the easiest and
cheapest (least cpu, etc.) way to tell if it's "good" (i.e. open)? I tried
using fstat() and fcntl(F_GETFL) and look for EBADF return and they work
fine (fcntl on Sol seemed just slightly "cheaper" than fstat). Are there
other ways to do this? Chris

[ Post a follow-up to this message ]

Chris Markle wrote :

> Given an file descriptor that may or may not be open, what's the easiest a
nd
> cheapest (least cpu, etc.) way to tell if it's "good" (i.e. open)? I tried
> using fstat() and fcntl(F_GETFL) and look for EBADF return and they work
> fine (fcntl on Sol seemed just slightly "cheaper" than fstat). Are there
> other ways to do this? Chris

dup() or dup2() ?

--
DINH V. Hoa,

"monde de merde" -- Erwan David

[ Post a follow-up to this message ]

"Chris Markle" <cmarkle@sendmail.com> writes:

> Given an file descriptor that may or may not be open, what's the easiest a
nd
> cheapest (least cpu, etc.) way to tell if it's "good" (i.e. open)? I tried
> using fstat() and fcntl(F_GETFL) and look for EBADF return and they work
> fine (fcntl on Sol seemed just slightly "cheaper" than fstat). Are there
> other ways to do this? Chris

You might try lseek(), and look for the same error, if you're into
timing system calls.

--
Måns Rullgård
mru@inprovide.com

[ Post a follow-up to this message ]

Måns Rullgård wrote :

> "Chris Markle" <cmarkle@sendmail.com> writes:
> 
>
> You might try lseek(), and look for the same error, if you're into
> timing system calls.

but lseek() won't work for streams 

--
DINH V. Hoa,

"monde de merde" -- Erwan David

[ Post a follow-up to this message ]

M=E5ns Rullg=E5rd wrote:

> "Chris Markle" <cmarkle@sendmail.com> writes:
>=20
>=20 
t and=20[vbcol=seagreen] 
ied=20[vbcol=seagreen] 
k=20[vbcol=seagreen] 
e=20[vbcol=seagreen] 
>=20
>=20
> You might try lseek(), and look for the same error, if you're into
> timing system calls.
>=20

Somewhat off-topic to the original post ...

But *why* does the OP need to know that piece of information?
If the program in question is so poorly coded that
the OP needs to check if a particular integer
value is a valid FD, I shudder to think of what
happens to allocated memory or to pointers
in that same code (unless he's looking to
track down an FD leak, e.g. missing close(),
someplace).

NPL

--=20
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

[ Post a follow-up to this message ]

DINH Viet Hoa <dinh.viet.hoa@free.fr> writes:

> Måns Rullgård wrote :
> 
>
> but lseek() won't work for streams 

It will set errno to EISPIPE if the fd isn't seekable, and EBADF if it
isn't open at all, so it can be used to tell whether an fd is open.

--
Måns Rullgård
mru@inprovide.com

[ Post a follow-up to this message ]

"DINH Viet Hoa" <dinh.viet.hoa@free.fr> wrote in message
news:etPan.419f8df5.47be063b.13fa@utopia...
> Måns Rullgård wrote :
> 
>
> but lseek() won't work for streams 

That's the idea. It's not supposed to work, it's supposed to fail. All
you care about is, did it fail because the file descriptor is invalid? Or
did something else happen?

The 'getsockopt' function is popular too, you either get -1/EBADF or you
don't.

DS

[ Post a follow-up to this message ]

Nick,

> Somewhat off-topic to the original post ...
> But *why* does the OP need to know that piece of information?
> If the program in question is so poorly coded that
> the OP needs to check if a particular integer
> value is a valid FD, I shudder to think of what
> happens to allocated memory or to pointers
> in that same code (unless he's looking to
> track down an FD leak, e.g. missing close(),
> someplace).

The OP (me) is dealing with OpenLDAP 2.1.x slapd which runs at a customer
for 140 straight days then spins. The spin has only shown its head twice in
a 6m period, so it's sorta hard to reproduce. The spin is related to
select() suddenly being called on the 140th day with a fdset that contains
apparently a closed fd. If we fix the loop in OpenLDAP (which we know how to
do) then OpenLDAP will shutdown (instead of spin) after it gets 16 straight
EBADF's from select(). That's a barely better option. We are reviewing 1
zillion lines of OpenLDAP code to see if we can see where close() is being
done without the associated cleanup, but may not find it. Until we do, we
thought maybe if we "cleaned up" the fdset to rid it of closed files after
we get this EBADF then maybe we could keep OpenLDAP running so the
customer's 1.5million users stay happy. Not the best of circumstances but
life's like that sometimes...

Chris

[ Post a follow-up to this message ]

Chris Markle wrote:
> Nick,
>
> 
>
>
> The OP (me) is dealing with OpenLDAP 2.1.x slapd which runs at a customer
> for 140 straight days then spins. The spin has only shown its head twice i
n
> a 6m period, so it's sorta hard to reproduce. The spin is related to
> select() suddenly being called on the 140th day with a fdset that contains
> apparently a closed fd. If we fix the loop in OpenLDAP (which we know how 
to
> do) then OpenLDAP will shutdown (instead of spin) after it gets 16 straigh
t
> EBADF's from select(). That's a barely better option. We are reviewing 1
> zillion lines of OpenLDAP code to see if we can see where close() is being
> done without the associated cleanup, but may not find it. Until we do, we
> thought maybe if we "cleaned up" the fdset to rid it of closed files after
> we get this EBADF then maybe we could keep OpenLDAP running so the
> customer's 1.5million users stay happy. Not the best of circumstances but
> life's like that sometimes...
>
> Chris
>
>
My apologies.  I jumped to an erroneous conclusion.




--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch

[ Post a follow-up to this message ]

On Sat, 20 Nov 2004 22:36:38 +0000, Chris Markle wrote:

> done without the associated cleanup, but may not find it. Until we do, we
> thought maybe if we "cleaned up" the fdset to rid it of closed files after
> we get this EBADF then maybe we could keep OpenLDAP running so the
> customer's 1.5million users stay happy. Not the best of circumstances but
> life's like that sometimes...

The easiest thing to do here is switch to poll() or even epoll(), and
then trigger off which fd returns as bad.
It _should_ also be possible, with a small amount of work, to trace where
the fd that comes back as bad is coming from. Although from what I
remember of the Openldap code base, maybe that isn't so .

--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

[ Post a follow-up to this message ]