This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Concurrency semantics of fork
- From: Ángel González <keisial at gmail dot com>
- To: David Niklas <doark at mail dot com>
- Cc: libc-help at sourceware dot org
- Date: Mon, 21 Dec 2015 00:06:42 +0100
- Subject: Re: Concurrency semantics of fork
- Authentication-results: sourceware.org; auth=none
- References: <20151218100656 dot 4e885fd4 at ulgy_thing>
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