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

Groups > comp.programming.threads > #2010

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

Cross-posted to 2 groups.

Show all headers | View raw

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
> On 25 Nov 2013 00:23:05 GMT
> Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> wrote:
> [snip]
>> I think this is completely unfair as it are those who worked on the
>> implementation and those who wrote the standard knew exactly the
>> two choices they had; they picked one of the two choices and you
>> seem to disagree with that particular choice.

[...]

> The only purpose for calling POSIX fork() in a multi-threaded program is
> to follow it with a call to exec*() (perhaps after setting up pipes with
> dup2() and the like),

For some people, the only purpose of fork they can possibly imagine is
as halfway useless incumbment on the way to executing another program
and - suprisingly and certainly by mere coincidence - the people who
wrote the phtreads specification and produced this litte gem are among
them. This makes two extreme standpoints, namely, "multi-threading is
useless and evil and 'cooperating sequential processes' is all God ever
wanted men to use" and "multiple processes running the same program are
totally useless, dangerous, outlandish, alien and socialist(!!1) and our
nice, shiny threads are a much better modern solution to any problem one
could conceivably need to solve" and neither of both is particularly
helpful in the real world (as extreme standpoints are wont to be),
especially considering all the moss which has been growing on this
controversy since it originated last century.

When a process forks, the contents of the memory in the address space of
the new process will be identical to that of the parent at the time of
the fork. Because only the forking thread is duplicated the child, the
effect on any other threads is that they stopped asynchronously at some
unpredictable (as seen from the 'sequential flow of time' of each
particular thread) time between executeing two instructions. This is
exactly what also happens when a signal handler is invoked because of an
asynchronous signal, hence, without special precautions, only
async-signal-safe functions can be called safely in the new
process. Another problem would be that POSIX demands that mutexes can
only be unlocked by the thread which locked them which implies that a
mutex which was held by some other thread than the one which forked
cannot ever be unlocked in the new process.

But signal handlers are not really restriced to async-signal safe calls
because they're free to do anything provided that 'main thread of
execution' was interrupted in an 'async-signal safe section' of the
code (the requirement is [paraphrase] 'all functions defined by this
specification shall work as described in the presence of asynchronous
signal except when function which is not async-signal safe is executed
from a signal handler which interrupted another not async-signal safe
function. In this case, the behaviour is undefined'). Likewise, there's
no restriction regarding what the forked process may safely do provided
all threads were executing something async-signal safe at the time of
the fork and no mutexes held by any of them will be touched in the new
process. And this is perfectly doable, especially considering that -
practically - some things are async-signal safe despite they're not
required to be, eg, blocking on a locked mutex (or semaphore). In an
ideal universe, implementations would be required to document how they
deal with multi-threaded access to shared resources and one could even
envision an API for safe forking modelled similar to the existing
facilities for dealing with asynchronous signals. In absence of both, it
is still possible to confine all other threads of a process to some safe
location during the fork and release them afterwards. 

This is obviously not going to work for the most general imaginable
case, where 'the process' runs arbitrary, binary only third-party code
whose actions can neither be controlled nor predicted but this is not
the only case.

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

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