* How to test if dlclose is a no-op? @ 2018-03-15 13:32 Thadeus Fleming 2018-03-15 14:40 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Thadeus Fleming @ 2018-03-15 13:32 UTC (permalink / raw) To: musl In the spirit of not “assum[ing] a certain implementation has particular properties rather than testing,” how can one test if dlclose is a no-op, as it is in musl, without breaking things if it isn’t? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: How to test if dlclose is a no-op? 2018-03-15 13:32 How to test if dlclose is a no-op? Thadeus Fleming @ 2018-03-15 14:40 ` Rich Felker 2018-03-15 15:24 ` Thadeus Fleming 0 siblings, 1 reply; 4+ messages in thread From: Rich Felker @ 2018-03-15 14:40 UTC (permalink / raw) To: musl On Thu, Mar 15, 2018 at 08:32:34AM -0500, Thadeus Fleming wrote: > In the spirit of not “assum[ing] a certain implementation has > particular properties rather than testing,” how can one test if > dlclose is a no-op, as it is in musl, without breaking things if it > isn’t? This sounds like an XY problem¹. Do you care about whether you can recover virtual memory space, whether the underlying fs objects remain referenced, whether there's a cycle of dtors and ctors running, or something else? FYI there is no clear answer to the question even on other implementations. glibc only sometimes unloads; there are corner cases and race-type conditions where unloading is impossible for them. You really should not be designing around an assumption/requirement that anything get unloaded. Rich ¹ http://xyproblem.info/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: How to test if dlclose is a no-op? 2018-03-15 14:40 ` Rich Felker @ 2018-03-15 15:24 ` Thadeus Fleming 2018-03-15 15:32 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Thadeus Fleming @ 2018-03-15 15:24 UTC (permalink / raw) To: musl I'm working on improving a system that makes some bad assumptions about dynamic unloading. While I'm not fond of dynamic unloading, I think it might be valuable to be able to distinguish between "this C library doesn't support unloading at all" and "if the planets are all aligned, unloading might work." Testing if dlclose is a no-op would allow me to make that distinction. On Thu, Mar 15, 2018 at 9:40 AM, Rich Felker <dalias@libc.org> wrote: > On Thu, Mar 15, 2018 at 08:32:34AM -0500, Thadeus Fleming wrote: >> In the spirit of not “assum[ing] a certain implementation has >> particular properties rather than testing,” how can one test if >> dlclose is a no-op, as it is in musl, without breaking things if it >> isn’t? > > This sounds like an XY problem¹. Do you care about whether you can > recover virtual memory space, whether the underlying fs objects remain > referenced, whether there's a cycle of dtors and ctors running, or > something else? > > FYI there is no clear answer to the question even on other > implementations. glibc only sometimes unloads; there are corner cases > and race-type conditions where unloading is impossible for them. You > really should not be designing around an assumption/requirement that > anything get unloaded. > > Rich > > > > ¹ http://xyproblem.info/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: How to test if dlclose is a no-op? 2018-03-15 15:24 ` Thadeus Fleming @ 2018-03-15 15:32 ` Rich Felker 0 siblings, 0 replies; 4+ messages in thread From: Rich Felker @ 2018-03-15 15:32 UTC (permalink / raw) To: musl On Thu, Mar 15, 2018 at 10:24:05AM -0500, Thadeus Fleming wrote: > I'm working on improving a system that makes some bad assumptions > about dynamic unloading. While I'm not fond of dynamic unloading, I > think it might be valuable to be able to distinguish between "this C > library doesn't support unloading at all" and "if the planets are all > aligned, unloading might work." Testing if dlclose is a no-op would > allow me to make that distinction. Well obviously you can do something like dlopen/dlclose/dlopen of the same library (a specially crafted probe library) with a ctor and observe whether ctor ran once or twice. But it seems like if you fix whatever bad assumptions the code has to the point that it runs correctly on musl, it will run correctly everywhere without caring what the behavior is. Rich > On Thu, Mar 15, 2018 at 9:40 AM, Rich Felker <dalias@libc.org> wrote: > > On Thu, Mar 15, 2018 at 08:32:34AM -0500, Thadeus Fleming wrote: > >> In the spirit of not “assum[ing] a certain implementation has > >> particular properties rather than testing,” how can one test if > >> dlclose is a no-op, as it is in musl, without breaking things if it > >> isn’t? > > > > This sounds like an XY problem¹. Do you care about whether you can > > recover virtual memory space, whether the underlying fs objects remain > > referenced, whether there's a cycle of dtors and ctors running, or > > something else? > > > > FYI there is no clear answer to the question even on other > > implementations. glibc only sometimes unloads; there are corner cases > > and race-type conditions where unloading is impossible for them. You > > really should not be designing around an assumption/requirement that > > anything get unloaded. > > > > Rich > > > > > > > > ¹ http://xyproblem.info/ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-03-15 15:32 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-03-15 13:32 How to test if dlclose is a no-op? Thadeus Fleming 2018-03-15 14:40 ` Rich Felker 2018-03-15 15:24 ` Thadeus Fleming 2018-03-15 15:32 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).