[unios] Re: IPC in the current OO model

[OJ Hickman]

From: OJ Hickman <hickman1@peak.org>

Anders Petersson wrote:
 
> 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.

High efficiency interaction needed for maximum graphic and multimedia
throughput. (Note: I do consider speed _very_ important)

Do you have other problems jumping threads solve?

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

Not all methods have to block. But if they change the inturnal state of
the object they will have to block syncronize.

> 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? :) )

Interesting. But if its going to be buffered non blocking IPC the
data stream consumer will need to have HIGHER priority then the producer
or the buffers may over run.

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

Yes. Direct interaction has one set of advantages/disadvantages and
cliant/server IPC has its own advantages and disadvantages.

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

What is the overhead of all this server stacking? I assume a simple
system
could be implamented on the 'root' kernel servers without extra layers
on top of them?

I see the kernel as an oversight unit tracking the objects and the
dependencies between them. It would also serve as a database of all
objects - the ones in memory and avalable to be loaded - that
loads them on a refrence to an object. Also, dependency tracking 
can identify unused objects and remove them from memory. IS this
what the OID servers do?

Unobtrucive and flexable, yet self managing.

> Very flexible, very generic, very neat.
> 
> binEng
_______________________________________________
"Imagination is more important then knowledge."
- Albert Einstein

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

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