tjr (12/14/82)
to: unix-wizards Here is my wish-list for UNIX: 1) How about device-independent I/O? Before you flame back saying "UNIX has device-independent I/O", please note that UNIX comes close, but no cigar. Pipes are very much different from terminals (flushing, EOFs), and files are not quite the same, either. Most of these differences come from physical constraints, but I think things could be better. Consider: we have a talking-terminal for a blind co-worker, and would like to augment its features with a UNIX process to handle the terminal I/O. This process would be exec-ed by .profile, would setup 2 pipes and fork a shell, setting the shell's stdin and stdout/err to be the pipes. It would monitor the 2 streams (keyboard->pipe1->shell-stdin, shell-stdout/err->pipe2->display) and do the appropriate modifications to its processing or to the streams. The trouble is that the shell cannot ever receive an EOF (nor can its children), so any command expecting to terminate on an EOF on stdin cannot be used. Closing the pipe will "send" an "EOF" to the shell (AND any children), which will shutdown the whole shebang; efforts to use SIGCLD to detect this and re-fork a shell have failed (environment would be lost, anyway). 2) How about a signal indicating "you have some I/O ready" ? In the above terminal-handling process, it is impossible to wait on "char ready from either the keyboard or the shell-output-pipe". You could read them both in NDELAY mode, and then sleep(1) if nothing was ready, but that is ugly. In practice, we use TWO processes, one handling each stream, and communicate the commands from the input-process to the output-process via signals (a very limited command-set!). 3) Why are vi, etc. so picky about their output? Many programs refuse to run unless they are directly connected to the tty. Why can't they assume that the user is more intelligent than the computer, and permit non-standard uses (when debugging a terminal, I might want to "tee" vi's output in order to later look at what was actually sent). Our blind co-worker is not very concerned about the lack of vi, but it's the principle of the thing... Tom Roberts ..ihnp4!ihnet!tjr (312) 979-6599
avie (12/15/82)
In reference to having a signal "when terminal input is available," this can be done. The signal is (I believe) SIGTINT. An appropriate ioctl call is also in order. The main restriction for this is that the user must be using the "new" tty driver. Although this can be done, I feel it is insufficient. The main problem is that signals (at least UN*X signals) are lousy to begin with. For example, repeated signals are lost if the signal is not reset quickly enough. Another problem is that a signal will cause a premature return of a system call (except for file I/O)! I guess if I were to create a UN*X wish list, it would definitely include improved signals. Avadis Tevanian, Jr. seismo!rochester!avie
tan (12/15/82)
I would also like to see improved signals, specifically: 1) a signal that would NOT kick you out of a system call, but would let you do something like set flags 2) since the kernel allows one person to be in there once/process a system call needs to be added to kick the user out of ANY system call they might be in 3) extra signals for the user ala 4.1 Also, how about some real inter-process communication: ala RSX, VMS etc SIII fifo's are a good start, but something is needed that does no blocking. as a series of tools UN*X is great, but as an operating system it is still lacking.
barmar (12/17/82)
1) Device-independent I/O: There is no such thing that is also useful. Every device is going to have certain operations that make no sense for it and certain operations that are unique to it. What would it mean to try to find the inter-record gap on a disk file? What does it mean to home the cursor on a tape? Or rewind a tty. Very few of these things make sense for a pipe, which is just a pure stream of characters. It would consider it a bug that there is no way to send EOF through a pipe, although I can understand why it works that way: EOF means that nothing more is coming - it is tty's, not pipes, that break the rule. 2) I/O ready signal: Well, if Unix had decent inter-process communications then the way you would do this is simple. On Multics we have things called "event channels", which are objects that your process can go blocked on. Another process can signal on an event channel, which causes the blocked process to wake up. You can block on multiple event channels, and detect which channel it was that the signal came in on. 3) video editors picky about their output: Well, if a video display managing program isn't connected to a tty, then what terminal type should it use? Don't say that it should use the user's login terminal, because I might want to be able to say: emacs >/dev/tty5 (actually, I don't know if this really works right, but it should!) barmar
padpowell (12/18/82)
How about process message passing/create/destroy? pid Create( [args as in exec] ) pid Destroy( pid ) : destroys named process, returns NULL if it does not exist. Send( addr, pid ) : send fixed number of bytes of message to process named. return NULL if does not exist. pid Receive( addr ) : blocks and waits for message from any process, returns pid of sending process pid Rec_specific( addr, pid ) : blocks and waits for message from process pid, returns NULL if pid is dead, nonexistent, etc. Reply( addr, pid ) : responds to message received from process pid, and will cause the message pointed to by addr to be placed in the senders message buffer. I personally would settle for very short messages, say 16 bytes. Even 8 bytes would be nice. Some advocates of message passing demand variable length messages. Would be nice, but is is debatable how usefull it would be. Patrick Powell, VLSI Design Group, U. Waterloo