Concurrency semantics of fork

[Ángel González]

On 18/12/15 16:06, David Niklas wrote:
> Hello,
> I've been following this thread and am somewhat confused.
Hello David

This thread is not at a beginner level, but I'll try to help you 
understand the crux of the matter:

>>> 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.
You can, if the original process was single-threaded. If it wasn't, it's 
not supported by POSIX, that's why Florian said «glibc supports malloc 
after fork in multi-threaded programs as an extension, I assume»


> I also consulted the man page and it guarantees thread safety too, which
> makes perfect sense, since most programs will need to malloc.
Being multi-threaded doesn't mean it's safe to fork at any point while 
it's running.

> Note, however, that freeing memory accessible by another thread may introduce
> a bug in the program.
After fork? This doesn't make much sense. Remember that after fork a 
multi-threaded program is now single-threaded.

Regards