Date: Wed, 19 Mar 1997 16:40:30 +1000 (EST) From: Stephen McKay <syssgm@dtir.qld.gov.au> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: freebsd-hackers@freebsd.org, syssgm@dtir.qld.gov.au Subject: Re: REPOST: dup3() - interesting feature-in-training or silly hack? Message-ID: <199703190640.QAA16421@ogre.dtir.qld.gov.au>
next in thread | raw e-mail | index | archive | help
"Jordan K. Hubbard" <jkh@time.cdrom.com> wrote: >The subject alone should have the kernel hackers all running for >shelter at this point - "Aigh! He's looking in /usr/src/sys!" >they yell. "Somebody stop him!!" :-) Jordan, Jordan, Jordan! I'm speechless! I think you should have a bit of a rest. Reality should return in a few hours. Unless you took a lot of it, then you might be OK in a few days. To be serious for a moment, this extra utility does not justify the cost. The cost is in degrading our process model. Before this change, a process had certain guarantees and had to ask explicitly for things to happen to it except for 2 things: external signals, and debugging (ptrace). Debugging has to be external to the process. External signals (unlike internally requested signals like timed alarms and child status changes) are usually fatal, and so cause a relatively simple cleanup and exit. The proposed "dup3" adds a new class of invasive system calls. Where does it stop? remote_chdir()? remote_putenv()? The guaranteed boundaries between processes that allow the programmer to be certain of what will work are eroded by the proposed dup3, and by all similar "pull the rug out from under it" mechanisms. (I forgot revoke() back there a bit. It, like external signals, is for fatal conditions only.) >So what's the use of it? To use in things like shells, so that you >can do stuff like this: > ># make world ><chatter chatter chatter - oh crap, I wanted this in a file> >^Z%1 Suspended ># bg > make.out ># <your shell is back - output spooling into make.out> > >This also works with fg, so you can foreground and redirect stdin, >stdout and stderr at the same time just as easily. There are at least two solutions to this problem, one simple, one complex. I have an alias that always stores the output of make into a file. I can then use tail -f to look at it in real time, or simply wait for later. The more complex version is to change your shell to allocate a virtual terminal to every command and manage the output. Thus, your shell could simply copy the output from make's virtual terminal to your main terminal (virtual or real), or when commanded, it could copy it to a file, or feed it to another pipeline. Similarly for input. This would not violate the sanctity of the processes involved. Then, if you wanted to optimise slightly, you could hack your kernel to plug the output of one virtual terminal directly into the output of another one, avoiding the overhead of the usual case of background processes writing to your terminal. That would be a nicer kernel project. :-) >Feedback most welcome. I think you've had an interesting learning experience doing this (tragic) thing to your kernel, but now you should put it all back. Stephen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703190640.QAA16421>