Re: object management and IPC a bit more formal

[Ludovic Courtès]

Hi,

On Tue, May 06, 2003 at 01:50:56PM +0200, Marcus Brinkmann wrote:
> OTOH, I think that it might be better to have a concept of subsystems that
> doesn't require subsystem usage, as this is not what subsystems were for (at
> least if you expect the persistent component to be reasonably connected to
> the non-persistent component, rather than running them in parallel like
> l4linux and Hurd could run in parallel).

Yes, I totally agree with that.

> See, I don't think that there is a requirement to make it work with global
> identifiers.  It should be easy to wrap the global identifier in the object
> handle with a local identifier, and look up the global one internal in the
> task when you do an RPC.  Then you can use a name server mechanism or some
> other way to update the global id table.

What I was suggesting in [1] was basically to use proc as a name server,
because proc already *is* a name server.  Basically, each task could
internally maintain a global ID table.  Whenever an IPC fails, the task
would ask proc what the thread ID corresponding to such or such PID is.
Since PID are local identifiers, everything is fine.

> OTOH, if you want to split up the thread number and PID world, you could use
> subsystems, but you could also just modify the task and proc server to have
> a flag "persistent", which could be the highest bit of the thread number
> and the highest bit of the PID.  Of course, that only gives you one "realm",
> but using a proxy proc server you could manage subrealms for users etc.

I prefer the above solution better since this one looks like
"special-casing" persistence while the above solution is much more
generic.

Thanks,
Ludovic.

[1] http://mail.gnu.org/archive/html/l4-hurd/2003-01/msg00002.html