laura@utcsstat.UUCP (Laura Creighton) (09/17/83)
Interprocess communication is perhaps the greatest weakness of unix. Most people try to use signals for interprocess communication. this is like trying to use a wrench to hammer nails home. it will work in a fashion, but not terribly well, and if you do something wrong you will break a perfectly good wrench. everybody and his dog seems to have their own way of dealing with interprocess communication. these days, I think that tunis is maybe the way to go. interrupts are converted to messages, and there is message handling in the kernel. Unfortunately, this is not unix. It is too bad that interprocess communication was a very new idea when Dennis Ritchie and Ken Thompson were designing the first unix. All the other attempts to get interprocess communication seem like the proverbial 'tacking a bag on the side of a ...' Very ugly. I think that interprocess communication is going to be very important in the future, but boy do I want one general way of doing it! Not hundreds. And I do not know the best way to do it. A friend and I ... no, lets be fair, Geoff Collyer came up with this, i just helped criticise it until it came into its present form... came up with a rather elegant and simple way to put semaphores into any unix kernel. (we think. there hasn't been time to test it, alas.) But if it does not get used by the people at Berkeley and Bell and HP and DEC and whereever else unix development work is being done then it is just a local kludge, even if it is more elegant and pleasing than the official solutions. And all local software that uses it will be an albatross on somebody's neck in the future, something i would not like to inflict on anyone. laura creighton utzoo!utcsstat!laura
condict@csd1.UUCP (Michael Condict) (09/18/83)
I'm no expert on the requirements and applications of interprocess communication (IPC) but I do know that any reasonable definition of what constitutes an IPC mechanism would include the now widely acclaimed Unix pipeline. Therefore it depresses, even saddens, me to hear so many people talk about ways to do IPC in Unix without any discussion of pipelines (except to immediately dismiss them as too weak). If there are any remaining adherents of the original Unix philosophy of Parsimony and Elegance in Design out there besides me, please make your voices heard! Surely there must be a reasonably simple way to remove the heredity constraints on pipelines, so that arbitrary processes can connect to and disconnect from one another, and an upward- compatible way to add the necessary concurrent processing features to pipelines (do we need more than a few things like mutually-exclusive read/write access, flexible permission codes and the ability to find out the number of processes that have a pipe open or the number of unread bytes sitting in a pipe?). If we really cannot generalize the pipeline construct adequately, then let us at least have the courage to throw it away, and replace it with your new-fangled IPC system. But please, please let us not allow Unix to grow fat and ugly, but rather taller and more powerful. No matter what gross iniquities are done to it in the name of progress, Unix will be around to help or haunt us for many years. It has become the FORTRAN of operating systems with respect to the number of different processors it runs on, the variety of tasks to which it is applied and (because of the former two) its longevity. We need to be very careful that we do not let the analogy extend any further than this. Michael Condict ...!cmcl2!csd1!condict Courant Inst., New York U. P.S. Here's a concrete proposal (someone must have already thought of this). Why not let pipelines have names that appear in the file system as a new kind of directory entry in addition to files and directories. Then they can live and die independently of processes and any process that knows the name of a pipeline and has the right permission can read or write to it. This is the VMS approach, with its mailbox devices, which are nothing more than a generalized pipeline of the sort I'm proposing (actually it's less, because the VMS designers forgot to make these mailboxes accessible at the command level for connecting processes together easily, but that does not argue against the utility of mailbox devices as an IPC). Of course we would preserve the current behavior of pipes with respect to shells creating them automatically upon seeing "|" in a command; only the explanation of what goes on internally would change. Actually, this proposal simply amounts to having a new kind of file, in which things are deleted as they are read and which is inherently sequential (seek is not allowed). Of course we would expect the kernel to go out of its way to store most or all of this kind of file in main storage, for efficient access. As for the concurrent processing features, like mutual exclusion, we can benefit from having these features available for pipes, files and devices alike, so there is no particular reason to associate them only with pipes.
ron%brl-vgr@sri-unix.UUCP (09/19/83)
From: Ron Natalie <ron@brl-vgr> Your solution to the games problem was already suggested but the problem was with games that you could not modify the source to. If you think small is beautiful why are you running V7? We are running a V6 based system with V7 file systems crafted in (but it still supports V6 ones too) and the Berkeley TCP/IP implementation backported (we gotta be on the net) but without such attrosities as systems that won't run on small PDP-11's or funny multiplexed files or packet drivers or protocol machines... -Ron
guy@rlgvax.UUCP (Guy Harris) (09/19/83)
In reply to several points on interprocess communication:
But sometimes the kernel must be changed, because there are certain
things that one just can't do in a subroutine library (although
it is amazing to me that Newcastle implemented a fully distributed
file system better than Sun's 4.2 without touching the kernel).
The best example is interprocess communication.
4.2BSD already has what seems to be a fairly decent IPC mechanism, with its
sockets.
everybody and his dog seems to have their own way of dealing with
interprocess communication. these days, I think that tunis is
maybe the way to go. interrupts are converted to messages, and
there is message handling in the kernel. Unfortunately, this is
not unix. It is too bad that interprocess communication was a very
new idea when Dennis Ritchie and Ken Thompson were designing the
first unix.
I'm not sure it was really that new an idea; several real-time minicomputer
operating systems had message send/receive facilities in the mid '70's.
Unfortunately it is true, though, that we have a proliferation of IPC
facilities. I suspect the 4.2BSD and USG 5.0 mechanisms can be twisted enough
to be based on one common system if someone wants to work hard enough (start
by taking the 4.2BSD system, add a new domain where the socket address is the
32-bit unique identifier used by 5.0, and add in whatever stuff is needed to
support the 5.0 facilities. The 5.0 system is based on an "IPC descriptor"
which is like a file descriptor, sort of, so the 4.2BSD descriptors may be
usable here.).
I'm no expert on the requirements and applications of interprocess
communication (IPC) but I do know that any reasonable definition of
what constitutes an IPC mechanism would include the now widely acclaimed Unix
pipeline. Therefore it depresses, even saddens, me to hear so many
people talk about ways to do IPC in Unix without any discussion of
pipelines (except to immediately dismiss them as too weak).
P.S. Here's a concrete proposal (someone must have already thought of
this). Why not let pipelines have names that appear in the file system
as a new kind of directory entry in addition to files and directories.
Then they can live and die independently of processes and any process
that knows the name of a pipeline and has the right permission can read
or write to it.
Somebody did think of that; System III and later USG releases of UNIX implement
pipes as a new type of inode - a "fifo". A pipe is just a fifo made up on the
fly with no directory entry pointing to it. You connect to a fifo by opening
it like a regular file.
However, the inability for unrelated processes to use pre-S3 pipes isn't pipes'
only problem. They cannot function in a record-oriented (i.e., message-
oriented) fashion; any record separators or lengths must be provided by the
process writing to the fifo. This means a malicious or deranged process can
foul up everybody else by writing an incomplete record to the fifo; I don't
know whether there's a protocol which guarantees this won't happen, but even
if it does exist it would probably add overhead. Furthermore, multiplexing
several communications over a fifo is difficult.
4.2BSD took the opposite tack from generalizing pipes. They added a new IPC
mechanism and implemented pipes as a special case of it.
The System V message queues are different beasts from pipes entirely. They
are message-oriented (rather than stream-oriented) and support multiple readers
and writers (you can put a "tag" on a message when you send it and can ask for
only messages with certain tags when you receive a message from a queue).
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guygwyn%brl-vld@sri-unix.UUCP (09/19/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> Bell UNIX (System V) does include IPC in the form of semaphores, shared memory, and message passing. Berkeley UNIX (4.2BSD) includes sockets. The problem I see is that no one known form of IPC or process synchronization mechanism is best for all applications. A "semaphore" device driver was distributed long ago on a USENIX tape; this seems like the simplest semi-portable addition one could make to a deficient UNIX in order to give it semaphores.
SHAWN%mit-ml@sri-unix.UUCP (09/19/83)
From: Shawn F. McKay <SHAWN@mit-ml> I know lots of people don't wan't to hear this; But here it is. "UNIX" (4.1BSD/V7/System xx), all should be compiled into one place, with all its winning features, and TOTALLY RE-WRITTEN, and called something else. Unix(tm) as I see it, is getting very hacked, and very old. It seems that every kernel I have seen so far, has more patches then I like to THINK about, never mind use as a system. Would unix not run a bit faster, look alot better, and be more portable, if some group out there, (keeping the 'Unix Philosophy' in mind), wen't along, and totally re-wrote it? And made it do as much as possable, (i.e. some from 4.1BSD, some from V7, and such), into a smaller sized kernel? Or at least, maybe it should be cleaned up? Clean the random hacks that are in it now, fix what bugs are known, (in a neat way), and comment it better. Unix never had to be 'well commented' before, but seeing how big, and somewhat hairy its grown, maybe its time? I also think, that there should be a 'unix' out there. Not the random stuff like 'unix'/'4.1BSD'/'xenix'/'venix'/'2.8BSD'/'V7', I think it might be a little better to have it something like: Pdp-11's: Unix Version x.x Vax-11's: Unix Version x.x Other: Unix Version x.x Mc68K's: Unix Version x.x I know, this is not easy, as 'everyone has a unix' now days, but its getting to the point where its hard to find a 'good' unix. as everyone has there own hacks, and some have others, (like stuff in /usr/sys/sys/syslocal.c, on 2.8 BSD systems), You never know what you are missing when you buy 4.1 over say V7. (Not that I can see you getting anything from V7 other then a 'good solid unix'). Well, enough said. Yours In Hacking(c), -Shawn (c)CopyRight 1983, All Rights Reserved,
ron%brl-vgr@sri-unix.UUCP (09/19/83)
From: Ron Natalie <ron@brl-vgr> How about throwing in world peace as well. -Ron
msc@qubix.UUCP (Mark Callow) (09/19/83)
You're right. Someone has thought of it. It's called a socket and it's in
4.2bsd. In the Unix domain a socket appears as a name pathname in the file
systems to which any process can connect a socket of it's own. A pipe
is in fact implemented by creating a pair of sockets and connecting them.
--
Mark Callow, Saratoga, CA.
...{decvax,ucbvax,ihnp4}!decwrl!
...{ittvax,amd70}!qubix!msc
decwrl!qubix!msc@Berkeley.ARPADBrown.TSDC@hi-multics@sri-unix.UUCP (09/21/83)
This message is empty.
gwyn@brl-vld@sri-unix.UUCP (09/21/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> The important thing about pipes is that for ordinary purposes a process does not have to be concerned whether a file descriptor it is using is attached to a file, a pipe, or a special file (device). This is not true of many other IPC schemes. Another nice thing about pipes is that they are file system entities, so fstat() works on them. However, 4.1cBSD (and I am told 4.2BSD) changed pipes to be socket pairs and return a bogus (struct stat) on pipes. This needs to be fixed, at least to the extent that (device, inode) is unique for each pipe. I actually liked pipes that were genuinely part of the file system; named pipes (FIFOs) and pipes are integrated into UNIX System III and V very cleanly. It would seem that with good block buffer handling this would still be a good scheme even in the presence of other IPC mechanisms. I think Berkeley had in mind piping between processes on separate CPUs when they changed to socket pairs.
steve@brl-bmd@sri-unix.UUCP (09/22/83)
From: Stephen Wolff <steve@brl-bmd> I think Berkeley had in mind piping between processes on separate CPUs when they changed to socket pairs. Yep, indeed they did! We are of course going to exploit this nifty feature in the rewrite of our large, multi-player, multi-process C3 simulation; we will no longer be hamstrung by the process and file descriptor limits, nor by the pipe restriction that all player processes share a (possibly distant) common ancestor. Since the 4.2 IPC syntax is domain-independent (i.e., uniform), we shall be able to pass the network hostname of each player as arguments at start-up and allow each program to decide whether it needs to use the internal (UNIX) or the network domain in the IPC calls. Personally, I think the integration of UNIX and networking via the 4.1c/4.2 IPC mechanism is a marvelous intellectual construct; my hat's off to the inventor. We don't do games, of course. But many must have noted this stuff will allow `Search' across the Net. (Whir click poing snap OOPS! Hello?) -s
eric@washu.UUCP (Eric Kiebler) (09/24/83)
Shawn has eluded to an idea which has intrigued me for years, so I guess
it is time to blurt it out...
Everybody wants free software. I would love to have a UN*X machine
at home, but I don't think that I want it without source, and I
can't (and will never) pay $43K or whatever a source license would
cost for a personal machine. This is not to say that Ma Bell (soon
to be Auntie SWB, Auntie ATTIS, etc.) does not deserve the money,
but rather that I can't/won't pay it.
So put together a non-profit organization dedicated to the development
of a portable operating system (or classes of systems). Have it build
all the verification suites and software and such for a living. Make it
wonderful enough that the "Happy Hackers" will flock to it. Get a sugar
daddy to support it (like the research cartels that some of the biggies
are putting together). Give the software results away.
1) We make lots of people mad because we steal their bread-and-butter
2) *Many* people get free software and are *very* happy.
3) *Everybody* gets source and every copy becomes different.
4) Economic incentive for producing os-clones is removed.
5) Economic incentive for software-driven hardware design is increased.
6) People get mad because "it's STILL not right" and do their own
thing anyway.
These are pro's and con's both. How important they are depends on
how much code I have been wading through that day compared with how
much I want to increase my personal standard of living. If we all
really believe the reactions we see at Usenix meetings when presentors
say "Sorry, we don't give it away, we sell it." then perhaps it is
time to look at something like this closely.
No, UCB wasn't supposed to do this (at least that is not the story
I heard).
I understand there is some outfit called "Freeware" which does this
kind of thing. They say "... give this away to all your friends, and if
you like it enuf, send us $25 ..." All the people I know with their
product have sent the $25.
I have not thought this through, as you can tell. Discussions welcome,
flames met with asbestos.
eric "re-porting the meta-wheel" kiebler
..!ihnp4!washu!erictim@unc.UUCP (Tim Maroney) (09/26/83)
About controlling the play of games:
Maybe I've missed something, but what is wrong with just using a
sh or csh script to check the system load and/or number of users
periodically, and turn off execute permissions on the games if the
load and/or number of users is too high? Your script can also use awk
with ps to kill running games, if you want. That is how it's done
here, and I am not aware that anyone has broken it. (That doesn't
mean no one has -- I haven't tried.) Of course, the game sources are
protected against reading, as are the game programs themselves, to
prevent private copies.
___________
Tim Maroney
duke!unc!tim (USENET)
tim.unc@udel-relay (ARPA)
The University of North Carolina at Chapel Hill
PS. No, I can't distribute our local program, but if you can't write
this yourself, you shouldn't be reading this group.JPAYNE@BBNG.ARPA (09/28/83)
At LSRHS, each game has a number (it's weight), where high numbers are for games that tend to use a lot of system time, and low numbers for games that don't take much time. To play a game you type "play game". The games are in a protected directory that only the "play" program can access. Play checks to see if the weight of your requested game PLUS the weight of all the other games being played, is greater than a certain limit. If it is it says, "Too much weight on the system," otherwise it plays the game. During school hours, when students (not hackers) are trying to use the computer, the allowed weight is VERY low (maybe one game at a time), but after school the weight is increased to about 4-5 games at a time (depending on the type). We have a lot of VIDEO games that NEVER stop running, and they are murder on the system! Oh yeah, the play program AND the games run at a nice of 39, so typing ^L in the editor tends to stop all games. It works well...
rbbb.rice%rand-relay@sri-unix.UUCP (10/05/83)
From: David.Chase <rbbb.rice@rand-relay> The free software aspect sounds fun, but the unbounded mutation of systems worries me. I would hope that some of my work would be useful to other people (and other people's useful to me) -- variations in operating systems can make this less likely. Thus I am willing to put up with a not-perfect-for-me environment because (a) the time I spend doing personal tailoring is essentially wasted, unless my personal tailoring is indeed my work (or it improves my productivity in some amazing way) and (b) anything I do can be used by anyone else running the standard system. The temptation to tinker with your environment is powerful indeed; I have installed and maintain local modifications in Gosling's emacs, so I have sinned, I guess. Some of my mlisp won't run on other people's emacs, so it's only useful to a few people (I think I'll send the modifications off to Unipress, for penance). I expect that RMS is capable of writing GNU and giving it away, but what then? Is this really progress? drc