Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #2006
| 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.
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 | Next — Previous in thread | Next in thread | Find similar
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