Date: Tue, 29 Apr 2003 12:28:00 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Narvi <narvi@haldjas.folklore.ee> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com> Subject: Re: Question about rtld-elf. Anyone?.. Anyone? Message-ID: <3EAED240.9A2C0534@mindspring.com> References: <20030429202837.L40030-100000@haldjas.folklore.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
Narvi wrote: > On Tue, 29 Apr 2003, Daniel Eischen wrote: > > Yes, this is true, but no threads library that we have currently > > tracks internal locks so they can be reinitialized after a fork. > > It is possible that a fork() will leave things in the locked > > state. But even if they were locked, you'd only see a problem > > if the forked program again became threaded. > > No, you would see the problem as soon as you tried to use a function that > used a locked structure, depending on how the dynamic linker did thinks > this might include any fiunction, including exec* - threads + forking > gives you really fascinating problems. How do you know that say malloc > state was consistent at the moment you forked? You really need > per-subsystem cleanups so that you won't occasionaly fail miserably. Its > not really the threads lib that can / should track locks, unless it comes > with its own copy of the subsystems. Exactly. It's a programming error. You don't know if they wanted the dlopen()'ed object in scope in the child process after the fork, or not, so if you have a dlopen()/fork() race, you can never know if it will get added (or removed, if we include dlclose() races) before or after the actual fork() has taken place. It's bogus for the programmer to use these types of interfaces without providing their own serialization so that they know for certain what the state of the mapped object is, after the fork(). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EAED240.9A2C0534>