Re: Concurrency semantics of fork

[David Niklas <doark at mail dot com>]

> >>> 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Â
>
That clears it up, Thanks.

> > 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.
I misunderstood, I thought that the discussion was referring to forking
and then calling malloc or using pthread_create? and then calling malloc.

> > 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.
Refer to the above.

Thanks again, David