[Spread-users] spread local message patch

Camp, TracyX E tracyx.e.camp at intel.com
Mon Sep 18 18:27:58 EDT 2006


I agree to a point, except then you add overhead in your application and
in the spread daemon for handling all the extra groups.  The keywords
where 'found useful'.  Your argument could also be applied to the
existing SELF_DISCARD flag, the point is to avoid common duplication of
code by moving complexity as low in the stack as possible.

As to how common this situation is, I couldn't offer an opinion, but for
the context where this was used, it was a common situation.

t.

-----Original Message-----
From: spread-users-bounces at lists.spread.org
[mailto:spread-users-bounces at lists.spread.org] On Behalf Of Daniel F.
Savarese
Sent: Monday, September 18, 2006 3:12 PM
To: spread-users at lists.spread.org
Subject: Re: [Spread-users] spread local message patch 


In message
<102A51607473A4449F0D3E2EF6FFCAD69B6F37 at orsmsx416.amr.corp.intel.com
>, "Camp, TracyX E" writes:
>Another patch for comment against 4rc2 that I've found useful for
>developing spread applications.  This patch adds a flag similar to
>SELF_DISCARD, but called LOCAL_MESS.  This flag indicates that while
the
>message is being sent to a group, it should only be delivered to
locally
>joined members.  Locally means on the node that the message was sent.

Why don't you simply create a unique group for each node which
only processes on those nodes will join, thereby containing only
local members?  A member of the global group can send messages
to its local group when it wants to communicate only with local
members.  I think most desired functionality can be handled at the
application-level instead of making special-case modifications to
the spread daemon.  By adding LOCAL_MESS you're in effect creating
a subgroup within a group, which to me indicates you should be using a
separate group altogether.

daniel


_______________________________________________
Spread-users mailing list
Spread-users at lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users




More information about the Spread-users mailing list