Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!killer!tness7!tness1!sugar!peter From: peter@sugar.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga.tech Subject: Re: IPCMessages -- A Prototype Keywords: IPC, standard, BADGE Message-ID: <2237@sugar.UUCP> Date: 2 Jul 88 13:19:19 GMT References: <6306@well.UUCP> <2139@sugar.UUCP> <6338@well.UUCP> <2158@sugar.UUCP> <6416@well.UUCP> Sender: news@sugar.UUCP Organization: Sugar Land UNIX - Houston, TX Lines: 73 In article <6416@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: > | From: peter@sugar.UUCP (Peter da Silva) > | > Second, caching makes list searching a rare event. A cache is just a > | > pointer to a port plus a flag to indicate if the cache is still valid. > | How about adding one more thing to a cache: the object and method it's > | a cache on. That way you can use the cache as an "opened" port, and > | not have to deal with the rest of the info again. That makes it a lot > | less obtrusive. > It's actually like that already; I just didn't specify that before. The > cache structure I'm using as a strawman is as follows: Good. Now then... > long Dispatch(object,cmd,cache) Might I make a suggestion. First, once the cache is set up, allow this: lresult = Dispatch(object, 0, cache) If the cache is invalidated, it still contains the class and command, no? This cuts down the baggage you need to carry around. I guess this could be a macro, but then the user needs to look at the cache internals, which is probably not a good idea. Finally, have a call to set up the cache ahead of time: lresult = InitCache(class,cmd,cache) This way, the cache can be though of as an opened port to the class and command. Also, this lets you do the "slow" location of the port outside the realtime loop. > The Object and Command structs contain the class and cmd (method) codes, > respectively, for this request. Note that the combination of object and > command uniquely define the server to be used, so no port actually need > be referenced explictly. Also, as noted above, the combination of object and cache also uniquely define the server to be used. > The fact that there are ports involved is deliberately obscure. Even if you use the cache in the way I described, it doesn't have to look like a port. In fact, now that I think of it, you don't necessarily even need to use messages and ports. This way the OOIPC stuff can have varying implementations: all OO, but maybe not all IPC. You could even have (say) an ILBM library that you register as the default ILBM server, so that the Dispatch function actually makes library calls instead of sending messages... you get all the flexibility of IPC, and maybe even higher preformance. > [Some] programmers are going to want an IPC mechanism more like PPIPC and some > are going to want OOIPC. It's silly to restrict people to using only > one paradigm. There may be a way to integrate the two approaches and > get the best of both worlds in terms of performance and features. Complete agreement. Which is why I encourage you to use PPIPC messages... > Curiously enough, I found that my original spec for standard messages > and objects may not be sufficient, and the result of the redesign is > starting to look a little like IPCMessages. Highly simplified, with > only 2 flag bits instead of 7 or 8, but its ancestry is clearly evident. > :-) Well, would it be possible to bring the actual message formats closer? What do you need that PPIPC messages don't provide? -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "Running DOS on a '386 is like driving an Indy car to the Stop-N-Go"