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

Groups > comp.programming.threads > #2013

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

Cross-posted to 2 groups.

Show all headers | View raw

Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> writes:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> 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.

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