On Thu, Nov 5, 2020 at 2:23 PM zero <daohu...@gmail.com> wrote: > If step 3 were to *really* unload A, how would B's code, which is still >> loaded and may be using symbols from A, continue to work? > > > Yes step 3 will not unload A, and A is still in memory, when dlopen(A) > again, it will return a handle, and will not do the init progress. >
So this is the same as will happen in OSv... Are you suggesting that it doesn't? Or just *asking* what happens? I think I tried to answer what should happen in my last email - please be more explicit if you tested OSv and Linux and found that OSv does the wrong and/or different-from-Linux thing. > So I ask how OSv implements the reference count. > When OSv loads a shared object A, either - as you called it - "explicitly" (dlopen()) or "implicitly" (needed by another object) - if it is not in memory it is loaded and its reference count is 1, but if it's already loaded, its reference count is incremented. The reference count of the object is also incremented when some other object uses a function f() and resolving it happened to resolve to f() in A. These reference counts get decremented back when those other objects get unloaded, and when A's reference count eventually drops to 0, it will be completely removed from memory (and all of A's static variables also get lost). > > If it depends on the path, then it will be a little different from dlopen > implement. > I don't understand what you mean here. What do you mean "depends on the path"? If you look at core/elf.cc, program::load_object() you'll see that indeed, already-loaded objects are looked up by object names, which are parts of the full path name of the file. Are you thinking, maybe, about the possibility that a single object has two names (perhaps a symbolic link, or something)e? If you want to explain to me that there is a bug, and/or difference from Linux, the best thing to do is to write a simple example and run it on Linux and OSv and demonstrate how it behaves differently (if it does). -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/CANEVyjvWvSrbczu9Gxzu2WPXaP-iRB3kob%3DVswYALa-8-3PGug%40mail.gmail.com.
