[Spread-users] spread daemon as library?
brlcad at mac.com
Mon Apr 17 22:29:05 EDT 2006
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.
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.
More information about the Spread-users