Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga.programmer Subject: Re: Inter process communication Message-ID: <1991Mar17.101410.13676@agate.berkeley.edu> Date: 17 Mar 91 10:14:10 GMT References: <1808@swrinde.nde.swri.edu> <12004@pasteur.Berkeley.EDU> <1899@swrinde.nde.swri.edu> Sender: usenet@agate.berkeley.edu (USENET Administrator) Organization: University of California, Berkeley Lines: 172 I guess I should join in on this thread -- a bit late I'm afraid. [every time I get back from Christmas in England, it takes me months to get back up to date. One of the areas I've studiously been avoiding is c.s.a.p...] Thanks to Dave Navas for pointing it out to me a couple of days ago. In (6 Mar), Rick Francis Golembiewski (rg20+@andrew.cmu.edu) started it with: > > > I'm wokring on an application that I'de like to implement with > seperatre tasks handling different sections (ie 1 task monityors user > IO, 1 task handles setting program parameters, 1 task does display). > > [........] I seem to remember some kind of library for inter-process > communication beign released, does anyone know what this library was > called? > As other people have suggested already, you're probably thinking of ppipc.library, available on Fish #290 (around June '89). This is still the current version -- it is stable enough not to have needed any updates. NOT because I've lost interest! It is still very much alive, and is an integral part on my own environment, especially the "IP:" pipe device (Fish #374). Dave Navas may not have made it completely clear, but he is the author of JazzBench, of which ppIPC is also a component. [NOT the creative part!! (:-))] Kent Polk has been using it a suite of Scientific Data Acquisition modules that are very impressive. To reiterate briefly, the idea of ppIPC is to use Exec messages -- which are fast and flexible -- but give them a framework that makes it easier for independently written program modules to communicate. First, it provides a "safety net" in the form of the IPCPort, which is protected against the disappearance of the task that is receiving its messages (a hazard with standard Exec ports). Second, its IPCMessage has a standard, but non-restrictive, structure that is "self-identifying" as to the function of the message -- similar in spirit to IFF (but a lot simpler!); a receiver can tell immediately from the header ID, and the various item IDs within the message, what the Client requires. (Or alternatively it can decide it hasn't the foggiest idea what the Client requires, and reject the message..) ======================================= In <10708@dog.ee.lbl.gov> (7 Mar), Jean-Noel MOYNE (jnmoyne@lbl.gov) writes: > > There is a good internal message system in the OS of the Amiga > [....] > > But there is another solution: Pete Goodeve has written a package > called IPC for "Inter Process Communication" (how did you guess ? (-:). Thanks for the plug, Jean-Noel! (:-)) > > Anyway, even if you want to go fast and use IPC for your project, > it is still a vey good idea to buy the RKM, and to read about exec's > message passing, since it's used everywhere on the Amiga (Yes, you can > actually say that AmigaOS is sort of "Object Oriented OS", no kidding). Agreed -- on all points. > PS: Pete's EMail is goodeve@violet.berkeley.edu Oops! Ektchewally, I'm on FIRST name terms with our computer...! (:-)) -- it's: pete@violet.berkeley.edu ======================================= In <1991Mar8.112635.1393@daimi.aau.dk> (8 Mar), Peter rb{k (poe@daimi.aau.dk) writes: > It might be my odin.library that you have seen. It was posted on > comp.sources.amiga some time ago. What IS this!? Is EVERYBODY who works on IPC named Peter?? (:-)) (I'm afraid I missed your system though -- have to see if I can find it...) ======================================= In <11854@pasteur.Berkeley.EDU> (10 Mar), David C. Navas (navas@cory.Berkeley.EDU) writes: > PPIPC (Pete & Peter's IPC) is very good for server-client modelled > communications, can get hairy for one-to-many broadcasts, and still doesn't > solve the disappearing ReplyMsg port, but I use it *always* instead of the > regular calls, because of the added protection they provide. Valid points. One facility I've wanted for a long time is a "broadcast" mechanism -- pre-dating ppIPC by quite a ways. [I remember doing some heavy thinking on it while driving up to Expo 86...] A partial solution is the "mani" facility (only available from abcdf20.larc.nasa.gov so far, I'm afraid) thaat clones a wide range of IPC messages to multiple destinations. I would like, though, a more general "broker" that accepts notifications of interest in "topics" from other processes, and handles the distribution of relevant messages between them. Some day. The ReplyPort question has led to quite a bit of correspondence between Kent and Dave which I hope you read, because I'm not going to reproduce it here [I tried, but the summaries kept ending up longer that the originals... (:-))] I hope my comments have some relevance. ........... I sort of get the feeling that *I'm* maybe missing something, but I've never worried all that much about Replies [...as many of my correspondents have noticed...(:-))]. There seem to me to be about three ways you could handle the problem. The most straightforward -- and the one I have usually adopted -- is that if you send a message WITH a ReplyPort address included, you WILL wait around til that message gets back; the ReplyPort is therefore just an Exec Port, not an IPCPort, and the original sender remains responsible for the message and its contents (unless transfer of some of the contents has been requested by flags in the message). This DOES require keeping a count of outstanding messages, and assumes that the Server is not going to go belly up before it replies, but so far I haven't had much problem with that. A second tack is NOT to expect a reply. The protocol has no problem with this -- though it may make some people uncomfortable...! In this case, though, the receiver of the message has to dispose of it when done, which probably (not necessarily) means that the message contents should obey all the rules for pointers and sizes and so on; if that's so, ANY receiver could dispose of the message and its data blocks without trouble. All data would have to be transferred to the receiver -- no pointers to strings in the Client code! The third idea is derived from what I understand Kent has done -- don't specify a ReplyPort directly, but keep passing the message on via PutIPCMessage()s until it gets back to its original sender. (In the two process case, this devolves to what I think Dave was talking about: using PutIPCMessage to return the message directly to its sender. Note that it isn't part of the basic ppIPC spec to expect that the ReplyPort field of a message is an IPCPort; it does no harm if it is, but it would be a real hazard the other way round!) It's critical here, of course, that all the cooperating programs "know what they're doing", because it's not part of the ppIPC specification, but, given the protective walls of specific port names combined with specific message IDs, this shouldn't be too hard. The tricky part is for a process to know where to pass the message; Kent handles this with his `Manager-launcher...', and -- from his comments -- it wasn't that easy to do, but it seems to work. If I understand Dave aright, his problem is with deciding what to do, in that sort of situation, when you try to pass on (or back) a message and it hits a "shut" IPCPort. You then have to dismantle and dispose of it yourself. As I said, though, you should only get involved in such a situation if you're using "well formed" IPCMessages, with every data block they reference having the "transfer" flag set, so that the data becomes the responsibility of whoever owns the message at that moment. With that true, you don't ever have to worry that you might bomb things by deleting something you shouldn't. Or have I indeed missed something...? ======================================= > > Now, can I join in on the discussion? I have some ideas... > [....] > > I was talking with Pete about this, but he abandoned me so he could go > play with his Amiga. Imagine that! (Pete; a sense of humor now...) > No, No... NO!! Something MUCH more important -- my new Yamaha keyboard! Of course when I get a MIDI box too, and CAN hook it up to my Amiga.... -- Pete --