[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: auth handshake and rendevouz objects

From: Marcus Brinkmann
Subject: Re: auth handshake and rendevouz objects
Date: Tue, 5 Nov 2002 18:57:03 +0100
User-agent: Mutt/1.4i

On Tue, Nov 05, 2002 at 06:39:45PM +0100, Niels Möller wrote:
> Do we really expect a high volume of rpc calls that transfer handles?

The question is, do you really want to implement a known race condition,
that is just bound to be triggered at some time?

Imagine an SMP system, and two threads happen to pass handles at exactly the
same time.  This could even be triggered by some other synchronization (eg
both threads run similar code and waited for reading on a read-write lock
that was held by the writer).  Such bugs are very hard to find if they
happen.  I would never feel comfortable with implementing them deliberately. 
I mean, we can be very happy if we happen to realize such problems before
writing the code.

> It's not obvious to me that one global thread won't do (either because
> the probability that it's busy is low, or because rpc calls involving
> handle transfers are serialized).

On the server side?  That would still not work because those notification
messages would be processed asynchonrously.  I am not sure what facilities
L4 provides to make it possible to continuously receive in a delegator
thread without introducing small races.

I didn't study your example right now.  I think we are touching here the
generic question of how to safely receive notification messages from servers
in clients.  I have pondered this in the past, and did not come to a
conclusion yet.  In Mach, we have the concept of buffering and the
possibility to receive a notification when the receiver is ready.  That is
plenty of meat to do it correctly.  I don't know what L4 provides.


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]