Newsgroups: comp.os.minix
Subject: Re: dumb question: do you fork()?
References: <937lsp$dnl$1@nnrp2.phx.gblx.net> <93fssi$la1$1@news.ilstu.edu> <slrn95ooht.qhl.pino+comp_os_minix@mud.stack.nl> <93idec$e3t$1@news.ilstu.edu>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <3a5ce771@news.isc.rit.edu>
Date: 10 Jan 2001 17:51:29 -0500
X-Trace: 10 Jan 2001 17:51:29 -0500, grace.isc.rit.edu
Lines: 62
XPident: aje9383
X-Original-NNTP-Posting-Host: 129.21.4.100
XPident: Unknown
Path: news.adfa.edu.au!clarion.carno.net.au!news0.optus.net.au!news1.optus.net.au!optus!news.mel.connect.com.au!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsswitch.lcs.mit.edu!bloom-beacon.mit.edu!news.kodak.com!news-nysernet-16.sprintlink.net!news.sprintlink.net!news.isc.rit.edu!aje9383
Xref: news.adfa.edu.au comp.os.minix:36494

[alt.os.development dropped--RIT claims it's invalid and therefore won't let
me keep it and post.]

In article <93idec$e3t$1@news.ilstu.edu>,
Tim Hockin  <thockin@isunix.it.ilstu.edu> wrote:
>In alt.os.development Martijn van Buul <pino+comp_os_minix@dohd.org> wrote:
>
>: Implementing threads as 'processes' leads to some issues. For instance,
>
>note firstly that threads which are processes (under Linux, anyway) share
>memory space with their creators.  This can easily be flagged and
>identified with a thread-ID.  This is NOT how linux does it.  In this
>discussion we've begun to mix terms.
>
>Thread: one context of control within a process
>Process: one running program
>Task: the OS control struct that defines both threads and processes.

I'd humbly submit that "Task" is an extremely fuzzy term; it can mean
different things in different operating systems.  (That is to say, we
probably want to avoid using it altogether in discussions.)  I've generally
heard of the kernel data structures called TCBs (Task Control Blocks), but
that may be an RIT-specific term.

In BeOS, a task is a thread.  (A process is called a "team", but that's more
an oddity than anything.)  In Minix, as we all know, a task is a device
driver; I guess you could consider it a kernel thread, since all the tasks
share the same address space.  I'm sure there might be some OS where the
term refers to a process; I think that was the case in MTOS, a rather aged
real-time operating system for the 68K series that I had reason to interact
with awhile ago.

>In my view, every thread is a seperate task.  Whether you want to assign a
>seperate PID to each thread has arguments both ways.

The only advantage to giving tasks pids that I can come up with (I'm no
expert, mind you) is that it's easier to kludge threads into an unthreaded
system (and API).  The disadvantages seem numerous to me, and mainly stem
from the fact that two essentially different entities overlap in the same
namespace--or, to put it another way, that a hierarchial structure is mapped
to a flat space.  (How do you send a signal to a process, as a whole, when
each thread has a PID--which one do you use?  How does that blessed thread
know the signal is for everybody, in general, rather than for itself in
particular?)

>: I have an account on a BSD box, which has a 15 minutes CPU-time limit for
>: each process (Unless you run things in the idle queue, but that's a
>
>:> The thread-is-a-task model is clean, elegant, simple, and obviously
>:> correct.  Anything else is a hack, IMHO.
>
>note that I said thread-is-a-task, not thread-is-a-process.

So what you're asserting is that every thread ought to get a control block
in the kernel?  Assuming threading is done at the kernel level, and not in
userland--which I think (pretty much) everybody agrees is the ideal
case--then there's not much of a choice, I guess.  (One could also assert
that, on a paged virtual memory system, pages ought to have page table
entries somewhere to keep track of them.)

-- 
Andrew Erickson
