Path: utzoo!attcan!uunet!lll-winken!lll-lcc!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.sys.amiga.tech Subject: Re: IPCMessages -- A Prototype Keywords: IPC, standard, BADGE Message-ID: <6523@well.UUCP> Date: 14 Jul 88 21:31:21 GMT References: <6306@well.UUCP> <2139@sugar.UUCP> <6338@well.UUCP> <2158@sugar.UUCP> <6467@well.UUCP> <2275@sugar.UUCP> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Organization: The Blue Planet Lines: 92 +--- From: peter@sugar.UUCP (Peter da Silva) | > [the cmd argument is a] | > pointer to a struct containing not only the method code, but any | > arguments that method requires, since most commands are more than just a | > single code. | OK. I got the impression this stuff was in the object. Silly me. I guess the other Peter thought this as well. OOIPC is not as different from PPIPC at this level than it might at first appear. | > | [ object servers that aren't seperate processes ] | > This is a *neat* idea. [...] Got more details on what you're thinking | > of here, Peter? | Off the top of my head: [top of the head details deleted...] I sounds sort of sensible. In fact, I'm revising the OOIPC design to include some sort of priorities for servers since this seems more useful than not. It might be fairly easy to add different classes of servers, i.e. message port servers, function servers, (other types?). I'm a little concerned about public memory considerations since this scheme would seem to mix things up pretty seriously, but obviously this isn't a real concern with current Amigas. [discussing message formats ...] | [ Basically looks like a PPIPC message with an extra pair of fields: an | object and an alias ] | Why pass the object in the call to Dispatch *and* in the command itself? I debated this a little, and I still may go and do it another way. Right now you just do Dispatch (command, object, cache) and the first thing Dispatch() does is: command->object = object; I was trying to make commands and objects distinct things, but perhaps that's not such a good idea since it's not strictly true. | I'm also not sure about the purpose of the "alias". Could you be more | specific? Sure. Suppose you have a server with one service port and you want it to serve lots of diverse commands and methods. You could do: RegisterService (port, OBJ1, MTH1, 0); RegisterService (port, OBJ1, MTH2, 0); RegisterService (port, OBJ2, MTH3, 0); and so on. This means that any of these types of requests could be posted to this same message port requiring the server to look into the command code and object class fields in order to determine what it is supposed to do. But this was already done by the library when it looked up the port in the first place. Why do it twice? Thus aliases. In order to make to lookup happen only once, the server can register a specific alias to be associated with a given service applied to a given port, as in: RegisterService (port, OBJ1, MTH1, 0); /* alias 0 */ RegisterService (port, OBJ1, MTH2, 1); /* alias 1 */ RegisterService (port, OBJ2, MTH3, 2); /* alias 2 */ and so on. When the server gets a command on its service port, it only has to look at the alias code to determine the nature of the request. In the example above, alias value 0 is a request for method code 1 on object class 1, value 1 is method 2, object 1 and so on. Using sequential integers as above makes for efficient switch blocks, or you could just pass the function pointer itself as the alias and just do (*com->alias)(com), if you're a trusting soul. | Otherwise, the structures are close enough for government work. Intentionally. I could have used vanilla PPIPC messages, but I have conceptual difficulties with all the flag bits and was trying to see if I could do it with fewer. | > By allowing `data' to point to an object, most of the flag bits under | > PPIPC become unnecessary. If something has a complex behavior, that can | > be encoded into its methods if it's an object. | That's cool. Got to worry about server loops, though. What do you mean by "server loop?" If you mean that servers can't normally be called recursively, then yes, that's something to worry about. I haven't really got a good answer for that one, except perhaps using software interrupt style service ports, or using your suggestion of functions for synchronous requests instead of messages. | -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)