Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!claris!sts!cohesive!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.lang.c
Subject: Re: threads for C/C++ under Unix?
Message-ID: <8893@goofy.megatest.UUCP>
Date: 20 Oct 89 23:28:58 GMT
References: <802@bbm.UUCP>
Organization: Megatest Corporation, San Jose, Ca
Lines: 21

From article <802@bbm.UUCP>, by darcy@bbm.UUCP (D'Arcy Cain):
...
> When I started reading this subject I thought I knew what a thread was. :-)
> Aren't threads just modified forks?  My understanding is that threads
> require kernel support because they involve sharing of system resources
> specifically the I and D space of the process creating the thread as
> opposed to forks which only share I space.

  [ Description of his concept of "threads" omited. ... ]

> ... can someone please tell me what a thread is.
> 

What we've been talking about is pretty much what you described, except
that we are not requiring that each thread get its own kernel-directed
scheduling. We are discussing the possibilty of one kernel-scheduled
task implementing several threads, scheduling them "by hand" as is appropriate.
That has advantages and disadvantages. It can make it easier for the threads
to share data-space, and under Unix at least, it will probably be lots
faster than doing one thread per task, (using shared data-segments, and
pipes, one would assume).