Re: SCO: "thread creation is about a thousand times faster than on

From: Linus Torvalds (
Date: Sun Aug 27 2000 - 22:06:40 EST

On Sun, 27 Aug 2000 wrote:

> On Sun, Aug 27, 2000 at 07:33:22PM -0700, Linus Torvalds wrote:
> > In article <>,
> > <> wrote:
> > >
> > >In the POSIX spec fork demolishes all threads in the child. This is the
> > >only sensible answer and it seems wasteful to ignore the rare sensible
> > >parts of the POSIX spec.
> >
> > What?
> I said it poorly. In the POSIX spec, the child is born single threaded.

Ahh. Yes.

I thought you meant "fork() kills the threadedness in the parent", which
definitely doesn't make sense. And upon re-reading, it wasn't actually
what you said at all. Mea culpa.

The fork'ed child not having any threads is the only sane semantics. After
all, it was just one thread that asked for a fork(), so it is only _that_
thread that gets copied. Anything else would be strange, to say the least.

Execve() is basically the same thing. Only one thread asked for the
execve(), so obviously only one thread is actually involved in it.

[ Side note: execve() has a number of interesting issues wrt various
  shared state, and Linux has not extended the "sane semantics" to include
  the POSIX kind of threads. Our execve() does not split off a new copy of
  the file handles etc: it breaks the VM sharing (obviously), and it also
  breaks the signal handler sharing (slightly less obvious, but it follows
  from breaking the VM sharing).

  But execve() does _not_ break the sharing of filesystem data or of file
  descriptor data. Which can result in some _strange_ behaviour, but
  basically it can be meaningful and may actually be what the user wanted.
  I really think that we should have added a "break these connections"
  mask to execve(), so that the user woul dget full control - and then we
  could truly export the sensible Linux "execve from thread" semantics as
  a POSIX extension to pthreads.

  As it is, only native threads can take real advantage of the execve()
  behaviour. Either by not sharing the state from the very first, or by
  taking advantage of the fact that the file descriptor state is actually
  shared even after an execve() if you ask for it. But this is certainly
  an area where Linux native threads could be more generic.

  Take this as a warning about the subtleties of threads. Also, realize
  that while I'm very confident that the Linux native threads are the
  "RightThing(tm)" conceptually, not everything those concepts might make
  possible and desireable has necessarily been implemented: nobody has
  ever asked for the extended execve() behaviour, so it's never been an
  action item for anybody. ]


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:20 EST