Date: Tue, 29 Apr 2003 21:59:26 -0700 From: Peter Wemm <peter@wemm.org> To: Narvi <narvi@haldjas.folklore.ee> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com> Subject: Re: Question about rtld-elf. Anyone?.. Anyone? Message-ID: <20030430045926.40FD82A7EA@canning.wemm.org> In-Reply-To: <20030429234505.X40030-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:
>
> > On Tue, 29 Apr 2003, Daniel Eischen wrote:
> >
> > > On Tue, 29 Apr 2003, Narvi wrote:
> > > >
> > > > No, you would see the problem as soon as you tried to use a function th
at
> > > > 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. It
s
> > > > not really the threads lib that can / should track locks, unless it com
es
> > > > with its own copy of the subsystems.
> >
> > In regards to inconsistent data (and not the state of the locks)...
> >
> > You could have use an atfork() handler to reinitialize any
> > inconsistent data. POSIX already defines pthread_atfork(),
> > and the kernel has at_fork(9) for kernel modules. Perhaps
> > pthread_atfork() could be utilized by libc, being careful
> > to detect the potential for threads first.
> >
>
> Well, i think we should gurantee something about the sanity of libc
> internals to the forked process.
This is getting a bit sidetracked here. Remember the issue at hand
is how to protect the ld-elf.so.1 internals in a pthread context. Not
how to recover from a fork().
One way I've seen is to have libc and the respective pthreads libraries
provide the public access to things like dlopen() etc. That way, the
threads package of your choice does its own serialization of the entry
points into the dynamic linker guts/internals. As John Polstra said
earlier, he has some thoughts about how to make the actual lazy symbol
lookup be thread-safe.
If I recall correctly, our old a.out based shared lib implementation did it
precicely this way. dlopen() was a function in libc, that called through
a vector into the guts of ld.so.1. The dynamic linker itself never provided
direct call access to this stuff. Some systems put these public functions
in a seperate library, -ldl. The ELF implemetation that we use does, and
doesn't give the threads library a chance to wrap them.
(And no, this is not an invitation for getting sidetracked on making
ld-elf.so.1 into libdl.so.1 as a service library, etc etc)
How would things go if we renamed the ld-elf.so functions to __rtld_dlopen()
etc and then had libc provide a weak dlopen() function that redirected to
__rtld_dlopen(), and give libpthread a chance to provide a replacement?
And of course, deal with making the runtime symbol resolution as John
suggested in the commit logs.
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030430045926.40FD82A7EA>