> > Absolutely. No-senders/dead port notification is one of the hardest parts
> > to port to a non-mach kernel, like L4.
> Please don't talk about these as if they were the same thing. Dead
> name notifications are not very important.
As said, sorry for the confusion. no-senders was meant.
> No senders notifications
> *are* important, and the use we make of them is critical in any
> Hurd-like system.
Could you please point at the files/functions that depend on
no-senders notifications?
To Mach novices: A no-senders notification is sent by Mach to a task
that is having receive-rights on a port X, as soon as the count of
outstanding send-rights for port X drops to zero. Or more sloppily:
as soon as no thread can send messages to this port anymore (not
counting send-once rights).
The problem here is that Mach maintains state w.r.t. the number of
clients that have send-rights to a port. Under L4, things change
a lot, because everything is stateless there. Under L4, every thread
can IPC to a "port", provided that this thread knows the appropriate
TID (which just happens to be the TASK/THREAD-ID of the thread that
is sitting on the receiving end of the IPC).
Moreover, L4 doesn't hide the specific TID namespace from clients,
as Mach does with its local-only relevant port-numbers. Security
issues must be dealt with in user-space, e.g. by the threads that
do the actual IPC or, more precisely, that proceed the messages
they receive.
Put another way: you always have "send-rights" to any "port" that is
listening to messages.
If you can't figure out a way to avoid no-senders notifications,
we'll have to emulate these too :-(. This would be very bad, from
a performance point of view. The only solution I'm seeing here
right now would go along these lines (somehow):
1. The only entity that is allowed to hand out TIDs (a.k.a ports) to
clients will be a user-land port-rights server task. (pr-server).
2. The pr-server will maintain state that is normally located in mach:
Not only reference count of send-rights, but also a list of TIDs
that got the send-rights (for notification purposes).
3. A client can explicitely relinquish a send-right by notifying the
pr-server about it. The pr-server will update its state and
notify whoever registered with it for no-senders notifications if
necessary.
4. Since there is no way to reliably/synchroneously detect the crash
of a potential IPC sender (a client), the pr-server will need to
regularly poll the clients that got send-rights. This can be
done somewhat like this:
4.1. A thread in the pr-server will regularly wake up and send
requests to all threads that got send-rights.
[This can be done sequentiall or on a scatter-gather basis,
but this is mainly an implementation issue]
4.2. A dedicated thread in every client will respond to the
pr-server requests if the client is still there.
If the client is not there, 4.1. will detect this.
4.3. pr-server will update its state and send notifications
to every client that registered with it, if the sender-count
of a port dropped to 0.
5. Clients interested in getting no-senders notifications about a
send-right port that they got from pr-server can register with
the pr-server (probably as part of the IPC that requested the
send-right in the first place [a boolean flag]). If they registered,
they'll get no-senders notification as soon as pr-server detects
this condition.
This is an awkward way to do it, especially because it is not synchroneous.
Sure, most of the time, clients will synchroneously relinquish send-rights
(case 3.) so we get reasonably quick responses. The problem is with
crashing clients etc...
The biggest problem however is one of performance. Since IPC performance
is so critical, this pr-server stuff adds quite a lot of overhead to
a very common operation. This is the reason that it would be very
useful to think of other ways in the Hurd itself (if possible).
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
