On Sun, 27 Aug 2000 yodaiken@fsmlabs.com wrote:
> On Sun, Aug 27, 2000 at 07:33:22PM -0700, Linus Torvalds wrote:
> > In article <20000827175449.A7759@hq.fsmlabs.com>,
> > <yodaiken@fsmlabs.com> 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. ]
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:20 EST