Thread View: comp.unix.internals
4 messages
4 total messages
Started by Robert Withrow
Wed, 23 Dec 1992 14:38
Does dlopen consume a fd?
Author: Robert Withrow
Date: Wed, 23 Dec 1992 14:38
Date: Wed, 23 Dec 1992 14:38
9 lines
803 bytes
803 bytes
The documentation is mute on this point. If one dlopens 30 shared objects (with no dlcloses), has one consumed 30 fds? If so, how does one merge a shared object without consuming fds? The doco implys that dlclose will unmap the shared object... -- Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA
Re: Does dlopen consume a fd?
Author: Guy Harris
Date: Wed, 23 Dec 1992 20:01
Date: Wed, 23 Dec 1992 20:01
12 lines
1068 bytes
1068 bytes
>The documentation is mute on this point. If one dlopens 30 shared >objects (with no dlcloses), has one consumed 30 fds? Modulo bugs in the library, no, one hasn't, at least not in SunOS 4.1[.x], and probably not in SVR4, either. SunOS 4.x "mmap()" is different from the "mmap()" originally proposed by Berkeley, in that if the file descriptor used in the "mmap()" is closed, mappings established with that FD are *not* removed. This was done, in part, precisely to *avoid* having shared libraries - and "dlopen()"ed objects - consume file descriptors. SVR4's "mmap()" behaves in that fashion, and I think BSD's new "mmap()" does so as well.
Re: Does dlopen consume a fd?
Author: Ronald G Minnich
Date: Wed, 23 Dec 1992 20:35
Date: Wed, 23 Dec 1992 20:35
22 lines
1616 bytes
1616 bytes
In article <16068@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes: >SunOS 4.x "mmap()" is different from the "mmap()" originally proposed by >Berkeley, in that if the file descriptor used in the "mmap()" is closed, >mappings established with that FD are *not* removed. This was done, in >part, precisely to *avoid* having shared libraries - and "dlopen()"ed >objects - consume file descriptors. One other problem it seems to me had closed file descriptors removed mappings would have been mysterious problems when users accidently close the wrong fd and e.g. blew away their library mapping. There are many user programs that simply walk through all fd's and close them all. Requiring these programs to now figure out what was an fd for a library and not mess with it might have been a serious problem. At the very least sounds like a support nightmare. Was this issue considered as well? ron -- you want windows? I got windows. 4608 by 3600, | rminnich@super.org 16 channels of sound, 4' by 6'. Fun. | (301)-805-7451 or 7312 Most abused words: open, scaleable, [more later] |
Re: Does dlopen consume a fd?
Author: Robert Withrow
Date: Sat, 26 Dec 1992 19:29
Date: Sat, 26 Dec 1992 19:29
9 lines
906 bytes
906 bytes
Thanks all for the info. A person at sun also confirmed that dlopen *doesn't* consume a fd: > No, it doesn't. This is possible because mmap'ed files stay mapped, even > after the fd you used to open the file with originally is closed. -- Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads