Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From: Kaz Kylheku <kaz@kylheku.com>
Newsgroups: comp.programming.threads,comp.unix.programmer
Subject: Re: Open issues in the specification for fork()?
Followup-To: comp.unix.programmer
Date: Sun, 26 Jan 2014 03:45:05 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 49
Message-ID: <20140125193706.829@kylheku.com>
References: <bfc933Fq0crU1@mid.individual.net>
NNTP-Posting-Host: X+c6YNb3AaWMPA3YfA4opg.user.speranza.aioe.org
X-Complaints-To: abuse@aioe.org
User-Agent: slrn/pre1.0.0-18 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.programming.threads:2060 comp.unix.programmer:5117

["Followup-To:" header set to comp.unix.programmer.]
On 2013-11-23, Markus Elfring <Markus.Elfring@web.de> wrote:
> Hello,
>
> I have read the document
> "http://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html" once more.
> I find that some details will need further clarification, won't it?
>
> 1. Do you interpret the wording
>    "... If a multi-threaded process calls fork(), ..."
>    from the section "DESCRIPTION" in the way that it is not specified which
> behaviour should be expected for the address space in an ordinary
> single-threaded process?
>
> 2. Is the wording
>    "... The fork() function is thus used only to run new programs, and the
> effects of calling functions that require certain resources between the call to
> fork() and the call to an exec function are undefined. ..."
>    from the section "RATIONALE" a contradiction to the previous information
>    "... Consequently, to avoid errors, the child process may only execute
> async-signal-safe operations until such time as one of the exec functions is
> called. ..."?
>
> 3. Is asynchronous-signal-safety also relevant for the single-threaded use case
> here?
>    Do you know interesting software design challenges or "realistic problems"
> for this situation?

The issue is that when a copy is made of a multithreaded process by fork,
it's as if the child is in a parallel universe where all the threads except
for the forking one have suddenly disappeared dead in their tracks.

So for instance, what if one of the threads in the parent was in the middle of
calling malloc, and some pointers in the malloc data structure are in a bad
state? The child inherits them that way.

You can write MT programs that handle fork and keep going.

In the global initialization routine of each module, have it register fork
handlers with pthread_atfork. Have every module do some correct thing when a
fork is going on. The pre-fork handler can ensure that threads are are
"parked" in some quiescent state, where they are known not to be updating
anything that will result in a trashed copy. The post-fork handler in the
parent can then clear the emergency so that things continue chugging along.
The post-fork handler in the child can do something similar, keeping in 
mind that there are no threads there.

It's a lot of responsibility, possibly complex coding and ... good luck 
getting third-party components to cooperate.