On Thu, 23 Jun 2005, Kamal R. Prasad wrote: > > --- Daniel Eischen <[EMAIL PROTECTED]> wrote: > > > (all?) of which > > > will be async-signal-safe anyway). Simple example: > > any lock that the > > > libc implementation needs to provide its > > functionality may be > > > arbitrarily locked by some other thread: eg, one > > thread calls malloc() > > > as another calls fork(): the original thread > > ceases to exist in the > > > child while holding a lock in malloc, leaving > > malloc() unusable in the > > > process. > > > How about doing some cleanup in a pthread_atfork() > routine? It can be done by the user or a libc/X stub > that gets called implicitly.
That may or may not be done in the future, but don't rely on it. In fact, it'd be nice to make it fail spectacularly :-) > > We do protect the malloc lock across a fork(), but > > that's it. > > > Isn't it possible that an application may genuinely > want to fork() out a child and not exec() another > process.? I don't care what it does, as long as it's allowed by POSIX. If you're going to fork() and not exec(), you might as well use pthread_create() instead of fork(). -- DE _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
