IPC in the current OO model

[Anders Petersson]

OJ Hickman wrote:
>Anders Petersson wrote:
>> 
>> >From: OJ Hickman (in unios@onelist.com)
>> >> From: Anders Petersson <anders.petersson@mbox320.swipnet.se>
>> >> 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.
>
>When did I imply that all object interaction had to block?

I'm quoting:
>> >Not all methods have to block. But if they change the inturnal state of 
>> >the object they will have to block syncronize. 
>> 
>> What do you mean with "internal state"?
>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 . . . 

You never said _all_ interaction, but from what you said, I get the
impression that much interaction is blocking. I could be wrong.

You talk alot about your "component system", but you've never given a
complete walk-throu of it. Why don't you write a document on it for the
UniOS site.

>> 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.
>
>No, it should be the ONLY way. This provides a very low level primitive
>that
>allows custom IPC to be implamented in user objects. The IPC can then be
>implamented in any way imaginable: buffered queues, over a network,
>paged
>memory mapings . . .

Isn't _this_ explicitly stating that all object interaction has to block?

And how do you mean that memory sharing could accomplish all the IPC types
you mention?

binEng