On Thu, Dec 20, 2001 at 01:54:18AM +0100, Marcus Brinkmann wrote: > A port is a message *queue*. messages are enqueued until a mach_msg (trap) > is made to receive the next message on a port. This can be seen as sending > an RPC to the receive port (for efficiency, and maybe other reasons, it's a > system trap in Mach).
[...] > Note that I am tending towards thinking how to get Mach IPC in L4 user space > completely. This can not be the goal of L4, for performance reasons alone, > I think. But maybe you can tradeoff some complexity by porting some > parts of the Hurd (libports), and I think this is what Thomas suggested. Granted, I was wording this way too pessimistic. Reading up the past discussion again, and thinking more about what we really use in the Hurd, getting most of the communication to be synchronous is likely to be the best option and should be feasible. There are only few cases where messages are not received through libports (select/poll and the signal thread being the most prominent). The problems don't go away by that, but I confess that my mind was too much set on the Mach IPC implementation. The past threads on this issue reminded me that the abstraction that the Hurd is built on is really "one up". If you are interested, this was the mail that put me straight again: http://mail.gnu.org/pipermail/l4-hurd/2001-November/000357.html So, please don't think I advertise that you port the Mach IPC system to its own L4 server. You will have to be more creative than that ;) Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
