🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.unix.internals
Article #2408

Re: Does dlopen consume a fd?

#2408
From: Ronald G Minnich
Date: Wed, 23 Dec 1992 20:35
22 lines
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]  |
Technical Details
Message-ID: <1992Dec23.203539.2829@super.org>
Path: arc1-ca.pugleaf.net!sparky!uunet!super!rminnich
References: <1992Dec23.143819.27180@rwwa.COM> <16068@auspex-gw.auspex.com>

Show Full Headers
Complete Article Headers
Newsgroups: comp.unix.internals
Path: arc1-ca.pugleaf.net!sparky!uunet!super!rminnich
From: rminnich@super.org (Ronald G Minnich)
Subject: Re: Does dlopen consume a fd?
Message-ID: <1992Dec23.203539.2829@super.org>
Sender: news@super.org (USENET News System)
Nntp-Posting-Host: metropolis
Organization: Supercomputing Research Center (Bowie, MD)
References: <1992Dec23.143819.27180@rwwa.COM> <16068@auspex-gw.auspex.com>
Distribution: usa
Date: Wed, 23 Dec 1992 20:35:39 GMT
Lines: 22