On Sun, Oct 30, 2016 at 3:44 PM, Benoît Canet <[email protected]> wrote:
> > > On Thu, Oct 27, 2016 at 3:04 PM, Nadav Har'El <[email protected]> wrote: > >> >> On Thu, Oct 27, 2016 at 3:06 PM, Benoît Canet < >> [email protected]> wrote: >> >>> We want the init of the elf object to use >>> the tls defined when the new thread is started. >>> >>> Delay this initialization. >>> >> >> So, program::get_library() runs some code (the library's initialization >> thread), and we want it to run a new thread. So wouldn't it make more sense >> to just create that thread *before* calling get_library(), instead of >> splitting the get_library() interface to two and complicating everything? >> > > We cannot create the thread at app initialization because we are suposed > to call app->start() later which create this thread. > Then maybe app->start() shouldn't have created this thread :-( But perhaps we're getting into a logic loop here - there was a big discussion recently on who should create a new thread for an application... I recently modified osv::run() to *NOT* create a new thread, and rather assume the caller created one (if it wishes to). But maybe we shouldn't continue to dwell on that. > >> >> By the way, I'm curious why Go cares on which thread the initialization >> happens.... Does the share library only work on one thread, the same thread >> it was initialized on? >> > > because the go runtime init use the TLS and the tls is thread related. So > we need the thread creation to init the tls then the go runtime init > will be able to work fine. > I still must be missing something: After Go starts, it can have many threads. Clearly, whatever initialization it does in its constructors needs to apply to all future threads - not just to the *current* thread. So I am still curious what it does that only works if you run the initialization inside the first thread. > > >> >> + // safety. >> >>> + std::vector<std::weak_ptr<object>> weak_objects; >>> + for (auto obj: loaded_objects) { >>> + weak_objects.push_back(obj); >>> + } >>> + // push the weak pointer on the stack >>> + _loaded_objects_stack.push(weak_objects); >>> >> >> Why did you need the temporary weak_objects vector? Why not push the >> objects directly on weak_objects? >> > > Because some library will load some other library like java does so we > need a stack to separatate objects. > I wanted weak_object because they do not mess with the refcounting used to > free stuff. > Yes, but wouldn't exactly the same be achieved if in the above loop you pushed obj directly onto _loaded_objects_stack, instead of pushing it first on a temporary stack and then pushing everything from the temporary stack onto your main stack _loaded_objects_stack? -- 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]. For more options, visit https://groups.google.com/d/optout.
