[unios] Re: IPC in the current OO model

[OJ Hickman]

From: OJ Hickman <hickman1@peak.org>

Anders Petersson wrote:
> 
> From: Anders Petersson <anders.petersson@mbox320.swipnet.se>
> 
> >From: OJ Hickman <hickman1@peak.org>
> >In my Component System each object has both a MMU protected code segment
> >and data segment. Many objects will have very sencitive data structures,
> >[internal states] such as link lists, queeues, etc . . .
> 
> So it's like a shared memory mechanism, then? Yes, in such case they should
> block.

Umm . . Yes. But in the Component Framework all code and data can be
shared. The purpose of the Oversight unit is to manage the sharing
between components. Unlike most microkernels Component Framework
will control the flow of execution between objects rather than
the flow of data.

To do this is seems that 1) the Oversight unit needs to have metadata
on the use and structure of all data objects 2) all interobject calls
will have to pass through thunks, maintained by the Oversight unit,
that verifi the paramiters as leagal and implament syncronization.

> Processes as objects is a perfect use of the object system:
> The CPU state is data, stored by the process OH (maybe the same thing as
> scheduler?). A process uses an executable file to run. Maybe it owns a data
> segment, or maybe such things are built-in, in some way. When a process
> opens a file, its just a common interobjectual use.
> (I'm here using the word 'process' as a thread that doesn't share anything
> in "non-objectual" ways - effectively an own process, but which can be run
> inside other applications).
> My way to do threads was to simply have processes as children of other
> objects. However, sometimes you want several threads to do the same thing,
> concurrently - multithreading. This I have problems with.

But threads are transient, in constant motion. It is the range of
movement
granted to the threads that constitute the actual dependencies between
objects in the Component Framework.

> >Yes, dividing the object overseer into a heierarcy of suboverseers is
> >the next logical step to take. Also simple to implament diferent
> >interaction polocies in diferent parts of the system.
> 
> This is just the kind of solutions we are looking for. Another example is
> stackable CPU scheduling. I can't promise it'll be fast enough thou, even
> if I think considerating speed as the judge is, in general, unfortunate.

Hold on. We don't need 'real' sub overseers. The only diference between
one
overseer and the next is the interaction polocies it implaments. The 
suboverseers should all be virtual manifeatations of the master
overseer.
The true overseer then references to polocy objects associated with
diferent
branches of the object tree. This will maintain the desired
structurization
without unecessary added complexity.

_______________________________________________
"Imagination is more important than knowledge."
- Albert Einstein

Omer James Hickman - hickman1@peak.org - ojh@hotmail.com
http://members.tripod.com/~OJ_Hickman - updated 12/28/98

------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios