Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!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: <2158@sugar.UUCP> Date: 22 Jun 88 04:08:18 GMT References: <6306@well.UUCP> <2139@sugar.UUCP> <6338@well.UUCP> Organization: Sugar Land UNIX - Houston, TX Lines: 69 In article <6338@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: > Me: > | There is nothing that says that the primitive structures the IPC items > | point to can't be defined at a higher level than Amiga native structures. > Having IPC item pointers that point to structures containing pointers is > what Pete Goodeve called, "the royal road to chaos," in his response to > a message of mine. If you take out the pesky network limitations then > you can have pointers to pointers all over the place -- it just won't > work over a network. The problem is that the Amiga is just chock-full of pointers to pointers all over the place. It's way too late to change that, so let's take advantage of the significant performance advantages we get from this. If you want to shove stuff over a network, use files. Use IFF. There's really nothing fundamentally wrong with either, except speed... and since you're actually copying the data over the network anyway an extra couple of context switches really won't hurt. > | I still think that a better high-level protocol for this stuff is necessary. > | Stuart Ferguson's own object oriented stuff is a good start.... [summary deleted] > This is a reasonably good summary of the concept. Implementational > details are different the way I imagine them, but this is the basic > idea. > | And of course the object server talks in IPCMessages... > Perhaps. My design doesn't quite jive with some of the basic > assumptions of the IPCMessage and IPCPort design. I noticed. Still, I think that we're really dealing with seperate levels of the problem here. You're concentrating on how the tasks meet each other, and I'm concentrating on what they say. > For example, the > ports need to be kept in a private list and not made available to > clients directly. By keeping ports insulated from client tasks, the > port for a given service (such as "IMAG/SHOW" in Peter's example) can > change on the fly without the server knowing it. Also, since clients > are not posting to ports directly, the ports are "safe." This is a > completely different concept than the IPCPort "reference count" idea. > There are other significant clashes that would need to be ironed out in > order to implement one under the other. My objection to this is speed. I can send a message to a destination port and get the response back in two context switches. I don't have to search any lists, private or otherwise. You paid some slight attention to this problem with your caching setup. But the cache is obtrusive, and doesn't behave in a predictable way. Also, you can completely implement your protocol under PPIPC, down to changing ports on the fly, just by searching the lists for every message. The overhead can't be any worse. I can't see using the OOIPC to do real-time stuff, like games. PPIPC would be just fine: you have a dependable fixed overhead to sending a message. Finally, I personally am not married to the high-level part of PPIPC. If you can come up with something that gives you the flexibility of OOIPC with the real-time reliability of PPIPC, I'll be happy to go for it. Come on. I keep asking. Don't make me beg. :->. But it's got to be at least as good as Pete Goodeve's stuff. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".