--- Daniel Eischen <[EMAIL PROTECTED]> wrote: > On Wed, 22 Jun 2005, Peter Edwards wrote: > > > On 6/22/05, Kamal R. Prasad <[EMAIL PROTECTED]> > wrote: > > > > > > The child process should be able to call any > system > > > calls it likes -without assuming that pthreads > from > > > the parent process have been copied over to the > child > > > process. I spose most implementations support > that. > > > > > > > There's more to it than system calls, though (most > (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.
> 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.? regards -kamal > -- > DE > > ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant http://members.fortunecity.com/kamalp [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is. ------------------------------------------------------------ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
