Thank you very much for your patient answer, it is really helpful! I will do some testing and learning next, thanks again.
Best regards! Nadav Har'El <[email protected]> 于2020年11月9日周一 下午7:53写道： > On Thu, Nov 5, 2020 at 2:23 PM zero <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/CADNiy7qS9c6_Py-%3D4ntOGkOE0AQcOkp4UX7710LXP1qPwBc13g%40mail.gmail.com.
