Make Current State Known

pileofrogs has asked for the wisdom of the Perl Monks concerning the following question:

I'm writing an app that has a number of attributes that can be in a whole bunch of different states. Other apps (that I'm going to write) need to know what state those attributes are in. What's the best way to make that information available to other apps?

Here's a simplified example. I have an app that makes coffee, an app that makes toast and another app that makes orange juice. It takes longer to make the coffee than to make the toast, so the toaster app wants to know how the coffee is coming along, so it can start making the toast at the right time. The orange juice app wants to know how acidic the coffee is going to be so it can choose a low acidity orange juice concentrate if the coffee is really acidic that day.

Maybe the coffee app takes connections on a socket and returns status info?
Maybe there's a text file that the coffee app overwrites whenever it has new info?
Maybe there's a db file that the coffee app updates when there's new info?

What's the best way to handle this?

(Needs to run on Linux)

Thanks!
--Pileofrogs

Update: Toast and OJ depend on coffee and know about coffee. Coffee doesn't know about toast or OJ. If I want to add scrambled eggs (and scrambled eggs depend on coffee), scrambled eggs is written with coffee in mind and coffee doesn't need to change.

Right now my favorite idea is a simple db file, like GDBM_File. Supports one writer and several readers, so there's no locking issues. The interface is super easy: just read and write to a hash.

Yet Another Update: In order for my db file idea to work, all updates need to be written to disk immediately (aka synchronously). Interestingly, GDBM_File's synchronous mode doesn't really seem to do anything. I had to tie/untie each time I wrote anything to get a synchronous behavior. MLDBM::Sync is probably a smarter way to go, but I'm out of time to spend on this part of the project...

Shared memory sounds good except I don't get how you can make it remotely secure. Can't any process write anything it wants to the shared memory?

Comment on Make Current State Known

Replies are listed 'Best First'.
Re: Make Current State Known by 5mi11er (Deacon) on Feb 10, 2006 at 21:20 UTC
Sounds like you are looking for information about "interprocess communications". A super search on those words came up with the following good candidates: Interprocess communication design Pipes (for interprocess communication) -Scott	[reply]
Re: Make Current State Known by saintmike (Vicar) on Feb 10, 2006 at 21:12 UTC
I'd use something like IPC::DirQueue to let tasks put jobs for other tasks in there. E.g., if the coffee task is halfway through, it could put a 'make toast' job in there for the toast to get started.	[reply]
Re^2: Make Current State Known by GrandFather (Saint) on Feb 10, 2006 at 21:20 UTC
Feed forward systems like that depend on the coffee app knowing about the toast app and its constraints - you end up with everything having to know about everything. If the apps simply publish their current status other apps in the know can find out what they need to know without the publishing app having to know anything about the subscriber app. DWIM is Perl's answer to Gödel	[reply]
Re^3: Make Current State Known by saintmike (Vicar) on Feb 10, 2006 at 21:28 UTC
Feed forward systems like that depend on the coffee app knowing about the toast app and its constraints - you end up with everything having to know about everything. Either the coffee task knows about the toast task or the toast task knows about the coffee task or a centralized manager knows about both the coffee and the toast task. Which one is the easiest/best maintainable implementation depends on the nature of the application.	[reply]
Re^4: Make Current State Known by GrandFather (Saint) on Feb 10, 2006 at 21:39 UTC
Re: Make Current State Known by traveler (Parson) on Feb 10, 2006 at 22:25 UTC
What I have done in cases like this is to put the information into shared memory. The subscribers then look at the appropriate value(s) and act accordingly. Do not forget that the publisher can change the value between the time the subscriber reads it and the time it starts to act on it. Regardless of the mechanism you use, there will be some occasions when things are not 100% in sync unless you have a mechanism to enforce the sync. HTH, --traveler	[reply]
Re^2: Make Current State Known by Perl_Inquiry (Initiate) on Feb 13, 2006 at 19:27 UTC
I was looking for the same thing and although I hev not yet delved into "it" (it being Perl Object Environment: POE), it looks very similar to what Java offers in its event / listener objects. http://poe.perl.org/?Tutorials	[reply]
Re: Make Current State Known by GrandFather (Saint) on Feb 10, 2006 at 21:14 UTC
Use XML::Simple to maintain a attribute file for each app. Apps that know about other apps they may be interested in dip into the attribute file for that app to see what state interesting attributes are in. You could fancy things up by using a lock file to mediate access during updates, but chances are that for a low update rate you can get away with retrying failed accesses and not worry about locking. DWIM is Perl's answer to Gödel	[reply]
Re: Make Current State Known by Anno (Deacon) on Feb 14, 2006 at 11:15 UTC
There is no single "best way" of doing this. Perlipc discusses the options. As for security of shared memory, it has ownership and permissions much like files do. Anno	[reply]