[unios] Re: IPC in the current OO model

[Anders Petersson]

From: Anders Petersson <anders.petersson@mbox320.swipnet.se>

>From: OJ Hickman <hickman1@peak.org>
>> From: Tril <dem@tunes.org>
>> On Mon, 21 Dec 1998, OJ Hickman wrote:
>> 
>> > As I understand the current OO model each object has a set
>> > of methods that are accessed over the IPC channels. Correct?
>> >
>> > I can only come up with two ways of doing this:
>> >
>> > 1: Interpret method tokens.
>> >
>> > 2: Setup a communication channel for each and every method.
>> > This would involve a system with thousands of open
>> > communication channels. The overhead would be monstrous!
>> >
>> > If someone can come up with another solution, do tell!
>> 
>> There is a third solution, that is used by the TUNES project:
>> Metaprogramming.  To perform an action, the objects are first strongly
>> type-checked, then linked directly together.  Since they have already been
>> typechecked, they can be treated as one composite object.  The
>> specification (we prefer that term to 'code' because a specification is
>> not in ASCII format, but made of objects) for the two together can be
>> optimized.  We believe this solution is both fast AND safe.

>Yes, I agree. I'm starting to think the best approch is to allow threads
>to driectly jump between objects. An object would need to set up a
>semephore,
>likely based on kernel/sceduler primitives, to prevent more than one
>thread
>from entering an object at a time. In this way information transfer
>between 
>objects/adderss spaces is done by the objects themselves not kernel IPC
>services. This would be much more flexable and eficient then
>cliant-server.

I dunno what this has to do with metaprogramming (as it is described).

But nevertheless thread jumping is an interesting idea. Or rather - the
problem that thread jumping would be an answer to is both interesting and
important.

What should happen when one object make use of another object? The server
should process the call with the CPU priority of the client. This supports
the jumping threads idea. But the server might have its own idea of how the
requested function should be implemented - maybe a single thread is better
suited for the task. And what if the client wish to do a non-blocking call?
This would have to be circumvented if jumping threads are used.

I think a solution with many threads, of which many are woken up only when
calls to them are made, is better. Yep - client/server. The client would
give the server some of its priority (or all, if the call is blocking), as
a "payment". The server itself does not need to have any priority at all -
it can just live on time shares donated by clients. (sounds pretty
idealistic, don't you think? :) )

Or what if both solutions are useful in combination? Sometimes thread
jumping is better, sometimes client/server... Other than that it introduces
some kernel complexity, I see no hinder to have both, they are both
possible in our current design. What do you think of it?

>The kernel in such a system would do little more then sceduel threads,
>allocate raw hardware and memory and provide a linkage database for
>the objects to connect to each other.

Almost correct... thanks to OID servers, the kernel does not need to take
care of object connections. A "root server" is still needed, I guess.
The memory allocation function would have to be provided by the kernel, but
could be further implemented by memory servers. The kernel would only
provide some sort of root memory allocation.
And threads... it's the same thing with them. The kernel implements a
simple root scheduler, on which additional schedulers can be stacked.

Very flexible, very generic, very neat.

binEng



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