Question about rtld-elf. Anyone?.. Anyone?

[Narvi]

On Tue, 29 Apr 2003, Terry Lambert wrote:

> 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 should either contain the object and the symbols or neither, not a
in-between situation. And it shouldn't cause a deadlock just because you
called a function that needs re-entering into the rtld or crashing because
you called dlsym and got handed a pointer pointing to nowhere.

> 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.
>

And exactly why would they have to assume that there is a problem?
Especially as a library function can call a dlopen() without their
knowledge (or really for that matter, call fork without their knowledge),
so there isn't anything they can do either. If it is allowable to use
functions from libraries you don't have source to in two different threads
(and I can't imagine there being a serious restriction not to) there is
nothing that can be done by the programmer, except possibly avoiding
freebsd.

> 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.
>

No mind reading is necessary - you have the choice of either delaying
fork() until the dlopen() completes or reaches some safe stage from which
cleanup is possible or you can schedule a fork() time cleanup that can
undo any state. Nothing in dlopen() specs claims it is not fork() or
threading safe. Non-thread safety would still give you at most one
concurrent copy and not p[rotection from fork().

> 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.
>

Thsi is not even close to similar situation.

> -- Terry
>