Path: utzoo!yunexus!stpl!bbm!darcy
From: darcy@bbm.UUCP (D'Arcy Cain)
Newsgroups: comp.lang.c
Subject: Re: threads for C/C++ under Unix?
Summary: Aren't threads just modified forks?
Message-ID: <802@bbm.UUCP>
Date: 18 Oct 89 04:17:44 GMT
Article-I.D.: bbm.802
Organization: BBM Bureau of Measurement, Toronto
Lines: 42

In article <1989Oct13.170846.29846@utzoo.uucp>, henry@utzoo.uucp (Henry
Spencer) writes:
> You need three pieces of kernel support:  a way to tell when a system call
> would block, a way to initiate such an operation without waiting for
> completion, and a way to be informed of completion.  "Unix" does *not*
> have such things; some *variants* of Unix do... and some don't.
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.  I understood a thread to
cause the following steps to be taken:

A process makes a thread system call similar to a fork call.

The kernel makes an exact duplicate of the calling process' stack space.
It makes no copy of the data space.

A record is kept of the fact that a process now has a new thread.  This
would be similar to the method of keeping track of child processes.

Other than the relation between the calling process and the sharing
of data space, the new thread is set up exactly the same as a process.
It is assigned a CPU time slice, can block on events and otherwise act
like a program.

Both the calling process and the new thread are placed in the ready to
run queue and in turn are eventually are given the CPU. The thread
however can branch to a different set of routines doing a specific
function in the overall program.  Normally this would involve blocking
on an event such as keyboard, mouse or something else.

When a process ends, the I and D space is not returned to the pool
until all threads end themselves or are killed by a signal.

If this roughly sketched activity is what constitutes a thread then 
I can't see how the kernel would not be involved.  If not can someone
please tell me what a thread is.

D'Arcy J.M. Cain
darcy@{cain,bbm}
some sort of linked list since a process may have more than one thread.