Re: [ot] Linux stdio question, howto find fopened files
From [EMAIL PROTECTED] Fri Mar 21 16:04:58 2003
On Thu, Mar 20, 2003 at 09:07:39PM -0800, Joey Hess wrote:
Walter Tautz wrote:
please retain the CC to rbutterworth
Subject: Linux stdio question.
On non-linux unix systems, one can reference __iob[]
to find all currently fopen()ed files
(e.g. when forking a new process one would generally
want to flush their buffers first, or perhaps close most of them).
Linux's stdio.h doesn't provide such an array of open FILE pointers,
or at least if it does I can't find it.
Any idea what they call it,
or how one can find all currently open FILEs?
Perhaps there is a better way?
A general guide to porting underlinux /debian would be appreciated.
I've never run into __iob, but it looks quite nonportable. A similarly
nonportable way in linux is to examine /proc/self/fd/.
I wonder if whatever unixes implement __iob have special kernel support
for it, or does libc just fill it in? I can't see how it could always
get at the info without kernel support. Just a point of personal interest..
Well, __iob is reasonably portable because it looks like it's a standard
part of a System V libc. In theory, I think glibc is supposed to support
the System V ABI, but it doesn't seem to have an __iob[]. I don't think
__iob is specified in any other standard, and different versions of the
System V ABI standard don't even define it in quite the same way.
Note that I wasn't claiming it was portable,
just that a similar mechanism (e.g. iob[], _iob[], or __iob[])
exists in all the UNIX versions I've seen over the last 20+ years
except for in LINUX. And it's not only the SysV versions: BSD 4.3
had this in 1982:
extern struct _iobuf {
char*_ptr;
char*_rms;
char*_base;
longint _sectr;
short int _flag;
short int _cnt;
char_links;
char_file;
short int _maxoffset;
longint _maxsectr;
} _iob[_NFILE];
and I'm sure that earlier versions had something similar.
Even if it did have an __iob[] you probably shouldn't be relying on
somebody else to keep track of the files you have open. You're the only
one who knows (or at least you're supposed to know) why you have files
open, so you should usually be trying to make an informed decision about
what to do with them.
Thinking ahead about things like that is a good habit, I've had no end
of headaches from listening to programmers going on about how the
compiler/runtime/server/whatever should do that for me when you tell
them their code is crashing because they didn't think about the side
effects of what they were doing.
Yes, I agree totally. The problem is that I'm not writing the
programs themselves, but some general-purpose library functions
for others to use. For instance, if one of these library functions
needs to do something like fork a new process, it should do some
cleanup first, in which case it will need to know which FILE *
descriptors are still open. Until now, that has been a trivial task.
I can work around this, but was hoping someone had a quick
and simple answer (e.g. it's called ___iob[]).
Thanks for the suggestions and comments anyway.
But wait, the fflush((FILE *)0) call needs this same information too,
so what I wanted can't be that unreasonable or difficult.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ot] Linux stdio question, howto find fopened files
On Mon, Mar 24, 2003 at 10:29:32AM -0500, Ray Butterworth wrote:
Note that I wasn't claiming it was portable,
just that a similar mechanism (e.g. iob[], _iob[], or __iob[])
exists in all the UNIX versions I've seen over the last 20+ years
except for in LINUX. And it's not only the SysV versions: BSD 4.3
had this in 1982:
extern struct _iobuf {
char*_ptr;
char*_rms;
char*_base;
longint _sectr;
short int _flag;
short int _cnt;
char_links;
char_file;
short int _maxoffset;
longint _maxsectr;
} _iob[_NFILE];
and I'm sure that earlier versions had something similar.
One problem is that the potential number of open files isn't a
compile-time constant on modern versions of Linux. I've spent the last
week on systems where it had to be raised to several hundred thousand,
but having an array that size would obviously be a very significant
waste of memory on small systems.
This is not to say that there isn't a way to get what you want, although
I don't know what it might be, but to offer a potential reason why
__iob[] hasn't survived into modern Unix. Even on systems that have it
I'm not sure whether you can rely on it when there might be large
numbers of open files.
Even if it did have an __iob[] you probably shouldn't be relying on
somebody else to keep track of the files you have open. You're the only
one who knows (or at least you're supposed to know) why you have files
open, so you should usually be trying to make an informed decision about
what to do with them.
Thinking ahead about things like that is a good habit, I've had no end
of headaches from listening to programmers going on about how the
compiler/runtime/server/whatever should do that for me when you tell
them their code is crashing because they didn't think about the side
effects of what they were doing.
Yes, I agree totally. The problem is that I'm not writing the
programs themselves, but some general-purpose library functions
for others to use. For instance, if one of these library functions
needs to do something like fork a new process, it should do some
cleanup first, in which case it will need to know which FILE *
descriptors are still open. Until now, that has been a trivial task.
Wouldn't it be easier to set the close-on-exec flag on all file
descriptors using fcntl()? You want to do this on low-level file
descriptors anyway rather than on (FILE *) streams, since not everything
uses stdio.
But wait, the fflush((FILE *)0) call needs this same information too,
so what I wanted can't be that unreasonable or difficult.
fflush(NULL) appears to iterate along _chain elements from _IO_list_all
(which I think is basically _IO_stderr). It's very much unclear to me
whether you can get at this from outside the libc, though, or if you can
whether it's safe: it's certainly not portable between libc versions,
for example, and if your code might be used in a multithreaded context
you'd need to know how to lock the list. Even in a library, I'd strongly
recommend finding another way.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ot] Linux stdio question, howto find fopened files
On Thu, Mar 20, 2003 at 09:07:39PM -0800, Joey Hess wrote: Walter Tautz wrote: please retain the CC to rbutterworth Subject: Linux stdio question. On non-linux unix systems, one can reference __iob[] to find all currently fopen()ed files (e.g. when forking a new process one would generally want to flush their buffers first, or perhaps close most of them). Linux's stdio.h doesn't provide such an array of open FILE pointers, or at least if it does I can't find it. Any idea what they call it, or how one can find all currently open FILEs? Perhaps there is a better way? A general guide to porting underlinux /debian would be appreciated. I've never run into __iob, but it looks quite nonportable. A similarly nonportable way in linux is to examine /proc/self/fd/. I wonder if whatever unixes implement __iob have special kernel support for it, or does libc just fill it in? I can't see how it could always get at the info without kernel support. Just a point of personal interest.. Well, __iob is reasonably portable because it looks like it's a standard part of a System V libc. In theory, I think glibc is supposed to support the System V ABI, but it doesn't seem to have an __iob[]. I don't think __iob is specified in any other standard, and different versions of the System V ABI standard don't even define it in quite the same way. Even if it did have an __iob[] you probably shouldn't be relying on somebody else to keep track of the files you have open. You're the only one who knows (or at least you're supposed to know) why you have files open, so you should usually be trying to make an informed decision about what to do with them. Thinking ahead about things like that is a good habit, I've had no end of headaches from listening to programmers going on about how the compiler/runtime/server/whatever should do that for me when you tell them their code is crashing because they didn't think about the side effects of what they were doing. -- Michael Heironimus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ot] Linux stdio question, howto find fopened files
On Fri, Mar 21, 2003 at 03:03:33PM -0600, Michael Heironimus wrote: Well, __iob is reasonably portable because it looks like it's a standard part of a System V libc. In theory, I think glibc is supposed to support the System V ABI, but it doesn't seem to have an __iob[]. I don't think __iob is specified in any other standard, and different versions of the System V ABI standard don't even define it in quite the same way. info libc ; i SVID SVID (The System V Interface Description) - ... The GNU C library defines most of the facilities required by the SVID that are not also required by the ISO C or POSIX standards, for compatibility with System V Unix and other Unix systems (such as SunOS) which include these facilities. However, many of the more obscure and less generally useful facilities required by the SVID are not included. (In fact, Unix System V itself does not provide them all.) ... So, the long and the short of it is GNU libc doesn't claim to fully support System V. I looked for __iob in the SUS3, for instance, and couldn't find neither hide nor hair... -- echo [EMAIL PROTECTED] eryyvZ .T pveR | rot13 | reverse -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ot] Linux stdio question, howto find fopened files
Walter Tautz wrote: please retain the CC to rbutterworth Subject: Linux stdio question. On non-linux unix systems, one can reference __iob[] to find all currently fopen()ed files (e.g. when forking a new process one would generally want to flush their buffers first, or perhaps close most of them). Linux's stdio.h doesn't provide such an array of open FILE pointers, or at least if it does I can't find it. Any idea what they call it, or how one can find all currently open FILEs? Perhaps there is a better way? A general guide to porting underlinux /debian would be appreciated. I've never run into __iob, but it looks quite nonportable. A similarly nonportable way in linux is to examine /proc/self/fd/. I wonder if whatever unixes implement __iob have special kernel support for it, or does libc just fill it in? I can't see how it could always get at the info without kernel support. Just a point of personal interest.. Oh and AFAIK, the stdio layer takes care of flushing buffers for you at the right times. Except for signals and abort type stuff. Also, note the GNU extention, fcloseall(3). -- see shy jo pgp0.pgp Description: PGP signature
[ot] Linux stdio question, howto find fopened files
please retain the CC to rbutterworth Subject: Linux stdio question. On non-linux unix systems, one can reference __iob[] to find all currently fopen()ed files (e.g. when forking a new process one would generally want to flush their buffers first, or perhaps close most of them). Linux's stdio.h doesn't provide such an array of open FILE pointers, or at least if it does I can't find it. Any idea what they call it, or how one can find all currently open FILEs? Perhaps there is a better way? A general guide to porting underlinux /debian would be appreciated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ot] Linux stdio question, howto find fopened files
On Wed, Mar 19, 2003 at 01:32:26PM -0500, Walter Tautz wrote: please retain the CC to rbutterworth Subject: Linux stdio question. On non-linux unix systems, one can reference __iob[] to find all currently fopen()ed files (e.g. when forking a new process one would generally want to flush their buffers first, or perhaps close most of them). Linux's stdio.h doesn't provide such an array of open FILE pointers, or at least if it does I can't find it. This seems to be a glibc question. Folks on news:comp.os.linux.development.[apps|sys] might know better. Referencing internal data structures is inherently non-portable. You might look in /proc/pid/fd/ which seems to have file descriptor numbers represented as symbolic links to the file(s) opened. fflush (NULL); flushes all fopen'ed files, but that doesn't mean writes are actually committed (you need sync/fsync for that). Any idea what they call it, or how one can find all currently open FILEs? Perhaps there is a better way? A general guide to porting underlinux /debian would be appreciated. Linux Standards Base? -- echo [EMAIL PROTECTED] eryyvZ .T pveR | rot13 | reverse -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
