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.html#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#tag_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(). -- Jamie _______________________________________________ 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
