[Spread-users] spread daemon as library?

[Morrison]

Kim,

Regardless of whether or not it's technically straightforward.  
worthwhile to others, or even plain goofy, it is something that I  
would certainly be highly interested in.  I've wanted to utilize  
spread through a library sans the separate daemon  for years for  
several projects I work with..

Running a separate persistent daemon process doesn't fit in easily  
with the political constraints that my group has to abide by  
(security policies, approval processes, etc).  Even more annoying is  
the simple deployment management aspect where it's one additional  
binary that has to be distributed, installed, managed, and tracked  
instead of simply being linked against our primary application that  
is already distributed, installed, managed, and tracked.

We're not interested in running several spread-enabled applications  
that all go through a single system Spread daemon, regardless of the  
technical benefits the single daemon  may provide to configurations.   
We have our application, and we generally just want it to take  
advantage of the communication benefits that Spread provides for  
communicating with other remote applications.

I don't want to treat it like a system service; the impact of that  
daemon from purely practical standpoints is too high.  I'd rather  
treat it as a group networking library API even if it was something  
as simple as #defining main to something else,  forking off that same  
main, and having some thin layer communicate with the daemon over a  
usual pipe.  The point is that it'd all be contained in my  
application, and that would save me headaches.

Cheers!
Sean


On Apr 17, 2006, at 9:21 PM, Kim Barrett wrote:

> We are developing a system that involves network communication among
> multiple processors, and in many ways spread looks like a good fit
> for us.
>
> However, one way in which it might not be ideal is the presumption of
> a spread daemon process which other processes on a given processor
> communicate with. It turns out that in our system the vast majority
> (probably all on some processors) of local client communication with
> the spread daemon on a given processor would be from a single process
> on that same processor. In the interest of reducing context switch
> and IPC overhead, we are starting to look at the possibility of
> making the daemon into a library that can be directly linked against
> by that one program of ours.
>
> It looks like the initialization of the daemon in main() in
> daemon/spread.c is pretty straightforward, and could be repackaged as
> a function to be called from our program. The hard part appears to be
> replacing the network plumbing between the client-side interface and
> the daemon's processing with a direct in-memory connection.
>
> Before possibly spending a lot of time going down this path, we're
> soliciting opinions from folks more familiar with spread as to
> whether this might actually be worthwhile or not, or whether it is
> perhaps just plain goofy to try this.