IPC in the current OO model

[Anders Petersson]

>From: OJ Hickman (in unios@onelist.com)
>> 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.

Of course everything should be sharable. But only when it's necessary
should objects block.

>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.

It's better to aquire access once, and then call the other object directly,
without any system interference. But if syncronized memory sharing is the
only means of communication, they can't cope with it alone. That's not how
I think things it be, however.

>> 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.

The range of movement? Threads don't really *move* when they execute. They
use different parts of the executable, but they stay in their place in the
systree and their PCBs remain in place.

>> >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.

Yes, we need stacking. Real stacking. This doesn't mean more complexity
than "parallell" managers - in fact it should _reduce_ the complexity
level. But more important, stacking brings generalisation, security,
correspondence to the user's view and flexibility/freedom in implementation.

binEng