On Monday 06 April 2009 06:29:01 Jamie Lokier wrote: > Mike Frysinger wrote: > > On Saturday 28 February 2009 17:06:49 Jamie Lokier wrote: > > > Mike Frysinger wrote: > > > > On Saturday 28 February 2009 14:16:30 Jamie Lokier wrote: > > > > > (I still haven't figured out if it's safe to use vfork with shared > > > > > libraries and lazy procedure lookup... doesn't apply for Jan's ARM > > > > > with no shared libraries of course). > > > > > > > > why wouldnt it ? there isnt any locking or such in the resolver, and > > > > it isnt like there are "speculative lookups" done randomly. there is > > > > an issue on Blackfin with thread safety, but that is only because we > > > > lack 64bit atomic load/stores and the FDPIC PLT is a 64bit > > > > descriptor. > > > > > > What about when another thread is calling dlopen(RTLD_GLOBAL)? > > > Doesn't that update a global list of DSOs to search? > > > > in a completely unrelated project, i revisited this. turns out, same > > exact thing can happen with fork(). POSIX even has quite a bit of > > explanation on the topic: > > http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_atfork.h > >tml#tag_16_402_08 > > > > the very last paragraph is such a nice summary: only async-signal-safe > > functions are safe after a fork/vfork in a threaded environment. > > > > none of the dl* functions show up in that list (scroll down a page or > > two): > > http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#t > >ag_15_04_03_03 > > In this case, though, we're not talking about calling dl* in the child > process after a fork/vfork. > > We're talking about calling _any_ functions which may be subject to > lazy symbol resolution in the child process - that includes > async-signal-safe functions like dup2().
presumably the resolver is smart enough to not add a library to the list until it's completely ready. especially considering the ldso has no locking in it that i can see which means the problem would be there regardless of forking. any thread doing dlopen(RTLD_GLOBAL) would trigger the same issue. i guess the only real way to figure it out would be to actually review the code ... i'll probably do that at some point, but i doubt it'll be anytime soon ... -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
