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?
That is not sensible, EITHER.
What is a thread? It's a "thread of consciousness" or a "context of
execution". Simple.
What does fork() do? It duplicates the context of execution with a
copy-on-write thing on the VM. Simple.
What in these two notions clash? Nothing. NADA. Zilch.
A fork() from a thread makes perfect sense. You get two contexts: they
basically share nothing but the initial register state. One of them is
a thread, the other one is a process but may choose to become a part of
a larger thread group later if it wants to (by doing a new clone() and
creating its own sub-threads).
There is absolutely no special case here. Linux does this quite
naturally.
The only special cases crop up if you do threading wrong. Which is
admittedly easy to do, because of all the historical crap that was
created because people didn't think about what a thread _means_.
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