This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Concurrency semantics of fork
- From: David Niklas <doark at mail dot com>
- To: libc-help at sourceware dot org
- Date: Fri, 18 Dec 2015 10:06:56 -0500
- Subject: Re: Concurrency semantics of fork
- Authentication-results: sourceware.org; auth=none
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