std-unix@ut-sally.UUCP (Moderator, John Quarterman) (12/13/85)
Date: Thu, 12 Dec 85 13:25:12 EST From: Arnold Robbins <arnold%gatech.csnet@CSNET-RELAY.ARPA> Just a final note on the P1003 Draft. I am dismayed by the lack of any IPC mechanism other than pipes and signals. While the draft explicitly says that one should not use signals for interprocess communication, it is well known that pipes and signals are not enough for the "real world". I realize that the System V IPC mechanisms are usually considered non-orthogonal and difficult to learn, and BSD sockets don't seem to be general enough either. But something should be done. It is hard to both innovate and standardize at the same time, but some sort of IPC should be added. If this is an issue that has been purposely delayed, OK. As long as the committee will acknowledge it as an issue, and eventually address it, I won't say anything else. [ You forgot FIFOs. It's an acknowledged issue, yes. -mod ] I hope my comments have been useful. Volume-Number: Volume 4, Number 16
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (12/19/85)
Date: Tue, 17 Dec 85 13:19:28 EST From: Arnold Robbins <arnold%gatech.csnet@CSNET-RELAY.ARPA> In article <3790@ut-sally.UUCP> std-unix@ut-sally.UUCP (Moderator, John Quarterman) writes: > Date: Thu, 12 Dec 85 13:25:12 EST > From: Arnold Robbins <arnold%gatech.csnet@CSNET-RELAY.ARPA> > > Just a final note on the P1003 Draft. I am dismayed by the lack of any IPC > mechanism other than pipes and signals. While the draft explicitly says that > one should not use signals for interprocess communication, it is well known > that pipes and signals are not enough for the "real world". > > I realize that the System V IPC mechanisms are usually considered > non-orthogonal and difficult to learn, and BSD sockets don't seem to be > general enough either. But something should be done. It is hard to > both innovate and standardize at the same time, but some sort of IPC > should be added. > > If this is an issue that has been purposely delayed, OK. As long as the > committee will acknowledge it as an issue, and eventually address it, I > won't say anything else. > > [ You forgot FIFOs. It's an acknowledged issue, yes. -mod ] I don't like to follow up to my own articles, but it occurred to me a day or two later that maybe Dennis Ritchie and/or ATT might be willing to donate Ritchie streams to the emerging standard as an IPC mechanims. I don't know a whole lot about streams, so they may be inappropriate, but from what I do know, it seems like they might could be used as a foundataion for both IPC and networking. This is just a suggestion. Comments from people who have actually used streams would be appreciated. The moderator makes a good point; FIFOs do provide pipes for non-related processes, which is a step in the right direction. I still think some other IPC mechanisms are needed though. [ Personally, I always thought FIFOs were rather lacking in several respects: I just wanted to point out that they are in the standard, flawed as they are. Considering that streams will be in some forthcoming iteration of System V, it seems unlikely that AT&T will make their implemenation public domain. However, there is probably sufficient published material (BLTJ 1984 and Portland (Summer 1985) USENIX) for interested parties to do their own implementations. -mod ] Again, I hope my comments have been useful. [Mail received after 12/19 will get stored until I get a new address, so, while mail replies are normally appropriate, they are not in this case.] [ The preceding paragraph was not by the moderator. This one is. Apologies for the long (five day) pause in posting things to the newsgroup. I only expected to be gone a couple of days, but had some problem with flights out of Mexico. I will be gone again from 22-29 December. I will try to find someone to be guest moderator during that period. -mod ] -- Arnold Robbins CSNET: arnold@gatech ARPA: arnold%gatech.csnet@csnet-relay.arpa UUCP: { akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold Real Unix hackers disdain wimpy languages like C and AWK in favor of /bin/sh. Volume-Number: Volume 4, Number 17