bug-hurd
[Top][All Lists]
Advanced

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

Re: behavior of NO SENDERS notifications when receive rights move


From: Richard Braun
Subject: Re: behavior of NO SENDERS notifications when receive rights move
Date: Fri, 30 Sep 2016 11:54:51 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, Sep 29, 2016 at 04:32:15PM -1000, Brent W. Baccala wrote:
> 'netmsg' is progressing nicely.  I'm developing a test suite for it, and
> have encountered an oblique case that's causing me some grief.
> 
> The problem is related to NO SENDERS notifications, which currently remain
> attached to a port if its receive right is moved.  This contrasts with the
> behavior of DEAD NAME notifications, which seem not to remain attached to a
> send right when it moves, and instead generate a PORT DELETED notification
> if the process's last send right is moved (or destroyed).
> 
> The Mach 3 kernel interfaces document, on page 60, includes the following
> statement:
> 
> (Note: Currently, moving a receive right does not affect any extant
> no-senders notifications. It is currently planned to change this so that
> no-senders notifications are canceled, with a send-once notification sent
> to indicate the cancellation.)
> 
> Well, this is exactly the situation that I'm wrestling with now.  Tracking
> NO SENDERS notifications across a network connection is a big headache.  It
> would be a lot easier if the behavior was changed as planned.
> 
> I don't even have to change the kernel to implement that behavior in
> 'netmsg'.  I can trigger that cancellation message myself, by just
> destroying the send-once right.
> 
> Of course, then the behavior would differ depending on whether you moved a
> receive right locally or remotely.  Notifications would follow local moves,
> but trigger cancellation on remote moves.  Programs could not depend on
> either behavior.

I don't believe the Hurd ever moves receive rights, and if it is, it's
most certainly very limited and local. The design of the system simply
doesn't need that feature. I completely understand the hassle you'd
have to go through for this and I don't really see the benefit, so
my opinion would be go ahead.

-- 
Richard Braun



reply via email to

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