|
|
Subscribe / Log in / New account

Ratiu: A tale of two toolchains and glibc

Ratiu: A tale of two toolchains and glibc

Posted Oct 3, 2021 0:13 UTC (Sun) by mpr22 (subscriber, #60784)
In reply to: Ratiu: A tale of two toolchains and glibc by iainn
Parent article: Ratiu: A tale of two toolchains and glibc

Can you point to (not merely assert the existence of) any real code that people are actually using to get things done that invokes dlclose() and actually expects it to do anything?

This is not a rhetorical question; I will cheerfully accept an answer of "yes, and here it is" :)


to post comments

Ratiu: A tale of two toolchains and glibc

Posted Oct 3, 2021 8:46 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (3 responses)

It is difficult to fathom such code, for the following reasons:

* The only formal change in semantics after calling dlclose() is that the application is no longer permitted to dereference certain pointers. Perhaps it's a tad obvious, but a conformant application must not dereference those pointers. Therefore, the application is not permitted to assume that dereferencing those pointers will, say, generate SIGSEGV, trip a guard page, or have any other desired or undesired effect, because the standard flatly forbids such dereferencing in the first place.
* The caller is expressly forbidden from interpreting the handle returned by dlopen "in any way." This presumably includes comparing it for equality with other handles returned by dlopen. Therefore, a conformant implementation may return the same handle every time you dlopen the same file, and keep an internal reference count (which the non-normative section of the dlclose standard explicitly calls out as a thing that implementations may do). If dlclose does nothing, then you just omit the reference count.
* Conformant implementations are also permitted to reuse closed handles, and a conformant implementation could even keep track of which object files were opened in the past and conspire to reuse their handle values if they are ever reopened in the future. Of course, if dlclose does nothing, then that's not really much of a "conspiracy."
* Maybe you're short on memory and trying to reclaim it? Well, that's not a very good reason at all. The pages which dlclose would free are backed by an object file on disk. If those pages are not in active use, the kernel should drop them automatically under memory pressure.
* Maybe you're trying to implement some crazy mechanism where you can replace object files without stopping and restarting the applications which are using them? Eh, that's probably a pipe dream anyway. Stopping and restarting your app is way easier than carefully shutting down an entire module of your program and then starting it up again. Also, the stop/restart dance is a general pattern, well supported by tools such as APT and systemd.

Ratiu: A tale of two toolchains and glibc

Posted Oct 3, 2021 12:26 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)

> * Maybe you're trying to implement some crazy mechanism where you can replace object files without stopping and restarting the applications which are using them? Eh, that's probably a pipe dream anyway. Stopping and restarting your app is way easier than carefully shutting down an entire module of your program and then starting it up again. Also, the stop/restart dance is a general pattern, well supported by tools such as APT and systemd.

Generally, I would think that the programming environment would need to explicitly support hot reloading of code. Something like Erlang comes to mind. Python attempts to support it with `reload()`, but things get…weird and I wouldn't really recommend it without a long list of caveats. Native code-targeting systems usually don't have the safety rails needed for such things.

Ratiu: A tale of two toolchains and glibc

Posted Oct 9, 2021 8:31 UTC (Sat) by sionescu (subscriber, #59410) [Link]

We rely on hot-reloading of C libraries when developing Common Lisp FFI wrappers: https://github.com/cffi/cffi/blob/master/src/libraries.li....

Ratiu: A tale of two toolchains and glibc

Posted Oct 3, 2021 23:09 UTC (Sun) by immibis (subscriber, #105511) [Link]

The really obvious thing to do with dlclose is to unload a plugin that's no longer in use. Especially if you have a long-running server application that may be reconfigured with SIGHUP.

Beyond that, I know one application that uses it for hot software upgrade - specifically UnrealIRCD.

Ratiu: A tale of two toolchains and glibc

Posted Oct 3, 2021 12:57 UTC (Sun) by iainn (guest, #64312) [Link] (3 responses)

No, sorry, I was being a bit facetious.

But dlclose being unusable genuinely baffles me, coming from a high level (e.g. .NET) perspective. *Obviously* you want to be able to unload a plugin when you're done with it. In .NET you just use an AssemblyLoadContext.

Ratiu: A tale of two toolchains and glibc

Posted Oct 3, 2021 13:50 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

It's funny that you mention .NET.

Because it does NOT support unloading of individual assemblies. You can "unload" the whole context but not individual assemblies.

Ratiu: A tale of two toolchains and glibc

Posted Oct 3, 2021 14:31 UTC (Sun) by iainn (guest, #64312) [Link] (1 responses)

I don't get what's so funny. You can spin an isolated AssemblyLoadContext, for an individual plugin.

You later Release() the whole context, which also cleans up any dependencies. That's a good thing.

Ratiu: A tale of two toolchains and glibc

Posted Oct 3, 2021 22:27 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, AssemblyLoadContext is a fairly new feature (starting from .NET 3), before that there was no way to unload assemblies at all.

Second, ALC can not be unloaded forcefully. If it's in use, then "unload" method simply does nothing. This wholly depends on GC being able to enumerate all the references to the context.

Ratiu: A tale of two toolchains and glibc

Posted Oct 9, 2021 8:28 UTC (Sat) by sionescu (subscriber, #59410) [Link]


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds