Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!adm!xadmx!rbj@dsys.icst.nbs.gov
From: rbj@dsys.icst.nbs.gov (Root Boy Jim)
Newsgroups: comp.unix.wizards
Subject: What kinds of things would you want in the GNU OS?
Message-ID: <19807@adm.BRL.MIL>
Date: 30 May 89 17:29:22 GMT
Sender: news@adm.BRL.MIL
Lines: 55

? From: Doug Gwyn <gwyn@smoke.brl.mil>

? As you seem to suspect, a "thread" has its own stack and state but
? shares code and data with other threads, whereas a "fork" has its
? own stack, state, and data but shares just the code with the other
? branch of the fork.

Hmmm. I've been saying we needed this all along. See next comment.

[rearranging a bit]
? By the way, Burroughs came close with their B5x00 and B6x00 series
? Extended Algol implementations.

EXEC-8 (Univac 1108) has `activities'. I believe you loaded a register
with an execution address and did an executive request to (yes...) FORK.
The parent continued inline, and the child went where the register pointed.
The `activity name' was either returned in another register or available
thru another executive requests. All code/data space was shared. There
was no stack.

? The supposed advantage of a thread is that it's cheap to create one,
? even compared with setting up copy-on-write for a fast fork().  The
? obvious disadvantage is that the shared data space requires use of
? concurrency controls among the parallel threads (e.g. monitors).
? Unfortunately, really good concurrency controls don't seem to exist
? at present.  Until someone devises a slick way to do this right in
? high-level languages, I'll continue to prefer separate processes and
? explicit data sharing.

Concurrency controls? On the data? On the u-block/proc-entry? Elsewhere?

EXEC-8 pretty duplicated most of it's PCT (u/proc) entry. After all,
they really are separate processes, they just happen to share the
same address space, uid, gid, etc.

As for the higher-level semantics, each thread needs to know it's
`instance number' (starting from zero) as well as its pid. All global
data used by threads is an array indexed by the instance number. The
stack would be duplicated, so local variable could be used as usual.

It would seem somewhat inconvenient to have to keep passing the
instance number to all called procedures tho. Seems like a language
extension might need to be defined.

And speaking of language extensions, how about guaranteeing that
unwind-protect, catch/throw, condition-case, etc, work in GNU C?

Let me take another guess at what you mean about concurrency controls.
How about semaphores. *REAL* semaphores, as Dijkstra intended them.
Something understandable. Something universal. I don't know why people
keep ignoring these things, as far as I know, they handle every
problem, multiprocessor, interrupt, critical sections, everything.

	Root Boy Jim is what I am
	Are you what you are or what?