Date: Tue, 29 Apr 2003 11:52:02 -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: <3EAEC9D2.AE47CC0A@mindspring.com> References: <20030429145307.L40030-100000@haldjas.folklore.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
Narvi wrote: > Peter Wemm wrote: > > Basically he's describing the exact scenario you're concerned about. The > > last paragraph suggests a better way. > > You will then need to make sure something sensible (and not a deadlock) > happens if fork() gets called at a time when dlopen() / dlclose() is > running in another thread. I think this is a non-sequitur; what's "sensible" in that case? Should the address space of the fork()'ed process contain the dlopen()'ed object, or not? It seems to me that this situation is a coding error on the part of the person who did not manually serialize access through a pthread mutex, so that the address space was controlled over the fork(), and the resulting process ended up with the state of its address space known to the programmer. I think it's OK to fail pretty spectacularly if a programmer is silly enough to cause this situation to occur in the first place; the idea that the protection against this type of coding error should be intrinsic to the library ignores the order-of-operation issue, which can only be resolved by the computer reading the programmers mind to determine the intent of the programmer. This reminds me of the kooks who pop up every once in a while and demand that libc functions not segfault when passed NULL pointers, and that all arguments be checked by the libc functions before they are used... an OS with training wheels, so to speak. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EAEC9D2.AE47CC0A>