Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.programming.threads,comp.unix.programmer Subject: Re: Open issues in the specification for fork()? Date: Mon, 25 Nov 2013 15:52:46 +0000 Lines: 53 Message-ID: <871u24xyup.fsf@sable.mobileactivedefense.com> References: <5291d497$0$15884$e4fe514c@news2.news.xs4all.nl> <87hab1kdvw.fsf@sable.mobileactivedefense.com> <52929869$0$15987$e4fe514c@news2.news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net n5e0Jdva+yVPwq6rsXZU5w5QrIFdHy+a6K/tmNBTZV2cQ47xk= Cancel-Lock: sha1:HwELspilAmp4uYEJ18oHlOK8HSE= sha1:NUBQwt56vJ1ighlWKLCpGy5kjYc= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Xref: csiph.com comp.programming.threads:2011 comp.unix.programmer:5035 Casper H.S. Dik writes: > Rainer Weikusat writes: > >>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. > > 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. I 'disagree' with this here: There are two reasons why POSIX programmers call fork(). One reason is to create a new thread of control within the same program (which was originally only possible in POSIX by creating a new process); [...] When a programmer is writing a multi-threaded program, the first described use of fork(), creating new threads in the same program, is provided by the pthread_create() function. The fork() function is thus used only to run new programs, because while this is not an outright lie, it's a carefully weasel-worded piece of disinformation supposed to lent some appearance of rationality to the entirely political bias of the author: Fork does not create 'a new thread of control running the same program' (which has a process chained to its ankle for some shitty, historical reason nobody in his right mind could possibly understand) but it creates a new process running the same program and this includes creating a new thread of control among some other things, most prominently, a new address space. There's also the practical concern that adding a new thread to some existing code unleashes 'immediate pthread madness' which is supposed to change the semantics of the working code retroactively: Something which used to be a perfectly legitimate use of fork is now considered to have undefined behaviour, regardless of how the interactions between the existing 'single-threaded process code' and the code running in the new thread actually happen to work. This means 'using pthreads' is meant to be an all-or-nothing choice: Either the process remains strictly single-threaded. Or everything has to be rewritten to be 'strictly pthreaded' insofar this is possible (which might not be the case since the code could rely on properties of fork pthread_create does not have) and this looks a lot like a useless effort to me, IOW, 'pthreads' trying to punish me for using 'traditionally written UNIX(*) code'.