Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #2060

Re: Open issues in the specification for fork()?

Cross-posted to 2 groups.

Followups directed to: comp.unix.programmer

Show all headers | View raw

["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.

Back to comp.programming.threads | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Open issues in the specification for fork()? Markus Elfring <Markus.Elfring@web.de> - 2013-11-23 19:05 +0100
  Re: Open issues in the specification for fork()? Måns Rullgård <mans@mansr.com> - 2013-11-23 18:32 +0000
  Re: Open issues in the specification for fork()? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2013-11-23 22:13 +0000
    Re: Open issues in the specification for fork()? Markus Elfring <Markus.Elfring@web.de> - 2013-11-24 06:56 +0100
  Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-24 10:27 +0000
    Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-24 15:39 +0000
      Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-25 00:23 +0000
        Re: Open issues in the specification for fork()? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2013-11-25 01:19 +0000
          Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-25 12:08 +0000
            Re: Open issues in the specification for fork()? Drazen Kacar <dave@fly.srk.fer.hr> - 2013-11-25 18:46 +0000
              Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-25 19:55 +0000
                Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-25 22:16 +0000
                Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-26 08:33 +0000
                Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-26 15:46 +0000
          Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-25 12:21 +0000
        Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-25 15:52 +0000
          Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-25 16:55 +0000
            Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-25 17:36 +0000
  Re: Open issues in the specification for fork()? Kaz Kylheku <kaz@kylheku.com> - 2014-01-26 03:45 +0000

csiph-web