Just can't get enough of that Moose!

Peter Mueller mueller@sc.ZIB-Berlin.DE
Wed, 24 Feb 93 13:06:52 +0100


> From winikoff@cs.mu.OZ.AU Tue Feb 23 23:35:20 1993
> Subject: Re: Just can't get enough of that Moose!
> To: moose-programmers@sfu.ca (Moose Project)
> Date: Wed, 24 Feb 93 9:29:32 EST
> From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
> X-Mailer: ELM [version 2.3 PL0]
> Content-Length: 2968
> 
> >    To be fair, the majority of the kernel itself will be doing hardware
> 
> Yes but I feel it can be encapsulated into a small module.

Agreed. Lets call it nucleus ;-)

> 
> > twiddling, so there isn't as much cause to make it portable as the rest
> > of the system. It would, however, be a starting place for a port if it
> > were in an HLL.
> 
  
> >    Actually, under Mach, at least, the opposite is true: tasks are the
> > kernel-scheduled, heavyweight objects, while processes are scheduled
> > within the task.
> 
> Standards .. pick your favorite :-)

Ok. Here I go: I prefer the term task which consists of several threads. A task is a 
heavyweight thing (don't want to say process :-). A thread is lightweight, thus thread
scheduling is very fast whereas task scheduling is much more slowly for the reason of
full context switches. Maybe we can think of another featherweight process type. 
(Sorry, I will precise this idea in a later mail. Now it's only a thought coming up to 
my brain ...)

> 
> > =>
> > =>Hmm. I think I detect the need for a glossary of terms :-)
> > =>
> >    Doubtless true, but we should probably decide what we want to do
> > before defining terms. Otherwise, we would probably end up with a
> > complete OS dictionary.
> 
> Hmm. But if we don't we could end up with a comunication problem. 
> :-)

Agreed. Maybe we should all add a glossary in front of our mails ;-)

>
> [Stuff about spin locks deleted. I've no experience with them.] 
 
> > =>Next question: Do we have some notion of transactions, atomicity etc.
> > =>(a 'la database systems)
> >    Not in the kernel, I think (unless we want exactly-once IPC semantics)
> > but we should be able to add them later.

Isn't it possible to create, for example, a transaction object which could be used
as an environment in which communication can took place safely? But I see the problem
when the kernel isn't safe at all.

> 
> > 
> > =>I was commenting on the choice of standards which (I think) were Unix type
> > =>standards. I (probly) am wrong here.
> > =>
> >    What do you mean by "Unix type standards"?
> 
> Standards which in my mind are more in the world of workstations then personal
> computers.
> 
> As I said - I'm rather vague in networks.
> 
> > 
> >    I'll put together my ideas on processes an IPC and post them when I
> > get a chance.

Fine.

Peter