cmcmanis%pepper@Sun.COM (Chuck McManis) (03/27/88)
Argh! IPC, such an innocuous TLA (three letter acronym), so many people have such disparate views on just what the hell IPC is that I am suprised you can talk about it at all. Let's set some ground rules, and maybe we can bring 3 meg of mail messages together into a fairly cohesive whole. First some definitions : IPC - InterProcess Communication IPC Facility - A programmatic means whereby two processes may pass and share data. Architecture - A specification of the abilities, and policies of a given facility. Implementation - A specification of the interface too, the code implementation of, the operating system restrictions, and the efficiency of a facility. Now, if you use these definitions, and I will be doing that here, then you will note that there have been a lot of messages on the implementation of an IPC facility, and a few on the architecture of an IPC facility, and a bunch on something entirely different. Now I don't mean to pick on Leo, but his message happened to be here when I had some time to sit down and espouse some opinions. Sorry Leo. What Leo disusses in his message (much of it is included below) it a user interface control system. It is built on *top* of an IPC facility and is *not* in itself an IPC facility. For the Amiga's part it *has* and IPC facility, and they are called message ports. An IPC facility allows two processes to share data period. Message ports do that quite nicely. The difficulty with message ports are that they do *no error checking*. Now that in itself is not a problem, it just makes programming with them a little bit tougher. Note included text (delineated by '>') is Leo's stuff ... > UNIX achieves IPC (usually) through pipes. One program's stdout is > connected to another program's stdin. On UNIX, this works great since, in > most cases, all user I/O through the program is through stdin and stdout. True, UNIX processes can send data through a pipe (which are often implemented as special case sockets). Usually, as in Leo's example, such exchanges are one way. > This is how most *users* accomplish IPC under UNIX. They say: >% foo | bar | baz | bletch | grep 'slime-mold' | lpr Ahh, but users don't accomplish anything, this is how they *use* pipes. And *pipes* use the IPC facility. There is a difference. By the same token, if the person who wrote 'foo' and 'bar' above did not *specifically* program them to be run in this way, then they *break*. This is important too. You see, 'bar', 'baz', 'bletch', and 'grep' in the above example are being used as "filters" and they were *designed* to be filters, otherwise nothing useful would happen. Take the real life unix command line : pepper% ps -aux | awk | lex | yacc | cc -o strange.stuff What happens here? Well you get lots of wild error messages because what 'ps' produces is not meaningful to awk and what awk produces is nothing like what 'lex' expects to see, much less 'yacc', but the output of yacc could be valid input to 'cc' except it doesn't have any valid input at all. So what you get is junk. Garbage in, garbage out. The point of all this is that the IPC facility that pipes are implemented on top of does not constrain the pipes in any way or how you use them, it just copies data from the output of one program into the input of another. This exact same facility is available on the Amiga although the CLI is not set up to let you at it this easily. And any programs that were written to use it, do so. Just like UNIX. > Unfortunately, it won't work for the majority of Amiga programs, since > their user interfaces are, by and large, not driven by > stdin and stdout. They're driven by gadgets, menus, requesters, mouse > movements, etc. The console.device does try and translate some of this > stuff into escape sequences, but there's just too much stuff here. Ordinary > UNIX-style pipes are extraordinarily useful, but they are nowhere near the > general solution we're looking for. Now, if you look closely you will notice it doesn't work for the majority of UNIX programs either. Just those that were designed with pipes in mind. An overall design philosophy in UNIX programming is that it is better to build lots of little tools that can be stacked, than one big tool with a zillion options. The same can be true of Amiga programs if the programmers choose to do things that way. My experience has been that ex-VMS programmers that write UNIX tools for the first time leave this out of their design. That's ok, because they still work, however when they realize the amplification effect they sometimes go back and rewack their code. Amiga programs have both a Stdin() and an IDCMP message port. If you had some way of describing Intuimessages it shouldn't be to tough to design an input handler to feed those to intuition. The results of course are not pretty and look a lot like the 'Journal' program running. But the key here is that this has *nothing* to do with an Interprocess Communication facility, it is a programming style question. >> Sockets: [ ... ] > > Now you're cookin'. Now all we need is a standard of command and > data transfer. Not even UNIX has this yet, largely because they've gotten > along so well with piping stdin and stdout all over the place for so long. > This isn't a drawback; the fact that UNIX only *really* supports ASCII > terminals has been a great advantage, making IPC relatively easy for them. > However, visually oriented systems will require a more general solution. I believe you are confusing the existing 'general' solution with a more constrained solution. All those UNIX programs were designed to deal with sockets, you can design your program to work with aREXX and get the same capabilities in a visually oriented system. Basically, while it would be neat to send your existing copy of Deluxe Paint a command to transfer its current image to your icon generating program, it is not possible. Why? because every program is a unique case, and there is no way to specify all of the useful commands you may wish to give to a program. It is not a bounded problem. The *ONLY* way this would work would be for Dan Silva to *design in* a process interface. Now he will probably do it because he is a nice guy and could see the benefits of doing this. It is even more likely if there is a piece of example code that shows what is expected of his code. But there is no way to telepathically tell his program what you want it to do. > I wonder how Sun did it with SunTools, if they did it at all? Can't do what you want to do with SunView. But you can watch for data from a socket or a pipe if you choose, that's how my Pente program communicates amoung the players, it is designed in. >> Semaphores and Shared Memory: [ ... ] > > The current Exec message and semaphore facilities fulfill this >aspect nicely, I feel. Yes they do don't they. Ok, so on with the new stuff ... What Leo is arguing for is an externally mandated standard for InterPROGRAM communication. And while it would be nice, it is *extremely* difficult to 'add on' after a system has gone through a couple of releases. The best shot you have here is aREXX. Get some example code out there that has a 'black' box interface to it (maybe something you could add into your regular intuition event loop) and then buy programs that use it and shun programs that don't. If Dan Silva releases a version of Deluxe Paint that uses it, every other paint program will follow suit. They already mimic the keyboard equivalents that Dpaint uses. The same is true for word processors/editors. If one uses it and sets the stage then they all will use the same commands. But there is no way you will ever get this thing to talk reliably to existing programs. About the closest you could come would be to use the 'stuff things in the input stream' technique which would make it impossible to use the Amiga while this was going on. AREXX answeres *every* requirement of Leo's and the other proponents of this type of communication except that it isn't free. InterPROCESS communication is another matter. In my opinion, you needn't reinvent the wheel. Just implement a socket library (or streams library) and use the same semantics/architecture as UNIX. The benefits are clear. a) It is a well understood and tested architecture. b) It adds to the attractivness of the Amiga because UNIX code may be more easily ported. c) It gives the programmer the flexibility of determining the type of communication, (datagram/packet). d) The interface supports several underlying network designs, there is no reason that DNET *and* amiga-tcp as well as basic message ports couldn't be used. e) It is well understood by many people and extensible. f) It facilitates moving to local area networks in the future. (say you want to send a REXX message to DPaint on a different machine for instance). Now given that *architecture* you can implement it in anyway your choose, whether it be by a new device or handler or library. That can be decided later. Well, it is sort of a weak finish but it addresses *every* IPC issue that I have seen raised that were architecture issues. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.