This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Concurrency semantics of fork


Hello,
I've been following this thread and am somewhat confused.

> > glibc supports malloc after fork in multi-threaded programs as an
> > extension, I assume.  There is quite a bit of code to support this
> > functionality.  I don't think we can remove it.  We have to fix it
> > instead.  
> 
> Correct. POSIX is the minimum we offer in many places and we should
> srive to solve real user problems and usage patterns. Particularly
> when we have already an implicit or explicit agreement to do so.

Once you fork I thought that meant that you could malloc as much as you
liked in either process since they are now separate processes with
separate memory regions.

I also consulted the man page and it guarantees thread safety too, which
makes perfect sense, since most programs will need to malloc. Note,
however, that freeing memory accessible by another thread may introduce 
a bug in the program.

vfork, on the other hand, does not permit malloc, for good reasons.

Thanks, David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]