Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.swapon.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 17:36:27 +0000 Lines: 42 Message-ID: <87ob58wfhg.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> <871u24xyup.fsf@sable.mobileactivedefense.com> <529380fe$0$15963$e4fe514c@news2.news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net K1hUdCfBRa1+PRgoY+TGKgGHAb4N0vVTWlM4dbqdNFTCO7I44= Cancel-Lock: sha1:1RZpBJIzJcSi7mo1wK/NG/xSUyk= sha1:7GZSmkutevOzoVaj3nZrBqR7qHk= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Xref: csiph.com comp.programming.threads:2013 comp.unix.programmer:5037 Casper H.S. Dik writes: > Rainer Weikusat writes: > > >>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); > > The changes for the threads didn't change how fork() worked or > didn't work. > > Even before threads were common, fork() had many, many issues, such > as fork()ing the whole status of the stdio library; atexit() handlers. > > fork() as a second thread in the same program was always full of > risk. > > You almost sound like someone who laments the loss of Linux' clone > model to the pthread model. I wrote something specific about the whole 'semantic unit of text' the first paragraph of which you quoted above and about another problem with the pthreads 'make no prisoners' approach. I don't see how the contents of your text would relate to that. I'm also not aware of any 'losses' affecting the Linux clone system call which were caused by adding the functionality necessary for supporting the pthreads signal handling model (which, while sensible in itself, is another 'disaster as designed' because it runs counter the intuition of a lot of people, who presumably use dedicate signal handling threads, thus, limiting the scalability of their code, despite there's no real reason for that except that they don't understand the purpose of the pthreads signal handling approach and consider it "scary and dangerous" because of that). While I don't consider stdio particularly useful, I wouldn't go so far to label it as 'risky on UNIX(*)' and the same is true for 'atexit handlers'. Using binary-only code with unknown behaviour is 'risky' but even these dangers can be dealt with.