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


Groups > comp.programming.threads > #2006

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

From Rainer Weikusat <rweikusat@mobileactivedefense.com>
Newsgroups comp.programming.threads, comp.unix.programmer
Subject Re: Open issues in the specification for fork()?
Date 2013-11-24 15:39 +0000
Message-ID <87hab1kdvw.fsf@sable.mobileactivedefense.com> (permalink)
References <bfc933Fq0crU1@mid.individual.net> <5291d497$0$15884$e4fe514c@news2.news.xs4all.nl>

Cross-posted to 2 groups.

Show all headers | View raw


Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> writes:
> Markus Elfring <Markus.Elfring@web.de> writes:

[...]

>>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. ..."?
>
> This is all about multi-threaded programs; and in such programs what functions
> you can call in the child after fork() is restricted to async-signal-safe
> functions.

This is all about the people who wrote the pthreads-specification
fighting the other tribe of people who are Violently(!!1) opposed to
multi-threading but purposely not defining any sensible semantics for
fork in multi-threaded processes. Consequently, the UNIX(*) standard is
useless here and best ignored: For any existing platform, the behaviour
is necessarily defined and code can be written to work in such an
environment.

[...]

>>   Do you know interesting software design challenges or "realistic problems"
>>for this situation?
>
> Yes.  Any form of malloc(), exit() instead of _exit(), etc, may lead
> to problems which likely happen randomly and probably after you've
> shipped the code to a customer.

If the failures are demonstrably random, that is, they occur because the
people who wrote the system code added stuff like

if (random() % 15 < 3) *(int *)(random()) = 12;

with some guard to trigger only in multi-threaded programs, that would
be a problem of the customer who should be more careful when chosing
suppliers.

Back to comp.programming.threads | Previous | NextPrevious 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