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

Groups > comp.programming.threads > #2002

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

Cross-posted to 2 groups.

Show all headers | View raw

Markus Elfring <Markus.Elfring@web.de> writes:

> 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?

No.  See the top of the DESCRIPTION section:

  The fork() function shall create a new process. The new process (child
  process) shall be an exact copy of the calling process (parent process)
  except as detailed below.

This adequately defines the single-threaded case.  The part you quote
details the behaviour in a multi-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. ..."?

No.  The part you quote from the RATIONALE section is an observation of
the typical use of fork() in a multi-threaded program (before the comma),
and a note about the consequences of the restrictions given in the
DESCRIPTION (after the comma).

The RATIONALE section exists only as background information which can be
useful for understanding why a particular behaviour is specified.  If it
appears to contradict the DESCRIPTION, the latter wins.

> 3. Is asynchronous-signal-safety also relevant for the single-threaded
> use case here?

No.  In the single-threaded case the state of the child process is known
so no limitations apply beyond any already present in the parent.  Note
however that ordering of operations on resources shared between the two
processes (e.g. file descriptors) is not defined unless explicitly
synchronised by other means.

-- 
Måns Rullgård
mans@mansr.com

Back to comp.programming.threads | Previous | Next — Previous in thread | Next 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