From: liljeber@hydra.Helsinki.FI (Mika Liljeberg) Subject: Re: tcsh 6.03 -- to patch or not to patch? Date: 30 Jan 1993 12:09:42 GMT
I suppose I must offer an explanation, since people are asking. :-)
In article <1kbmj0INNc0l@matt.ksu.ksu.edu> probreak@matt.ksu.ksu.edu (James Michael Chacon) wrote:
> gleasokr@rintintin.Colorado.EDU (Kris Gleason) writes:
>
>>I got the latest-and-greatest tcsh binaries, linked with libc.so.4.2
>>from sunsite.unc.edu. As you might have guessed, it was a big problem when I
>>installed it... had problems with pipes (rusty pipes). Basically, at
>>seemingly random times, commands executed through a pipe would either
>>stop running early (only fixed by ^C), or kill the shell (the shell caught
>>user signal 2 and exited).
>
>>So, I got the source, applied the included diffs, recompiled with all new
>>stuff, and got identical results. I looked at the diff file, and could make
>>very little sense out of what was happening with SIGUSR2, if anything.
>
>>Finally, I recompiled again, this time without the diff. The compile went
>>smoothly, and the new binary has had no problems with any pipes. In fact,
>>it has no problems that I have noticed at all.
Sigh. I _knew_ something like this would happen.
>>So, if you're still with me... I was just wondering why the original source
>>was changed in the first place. Was this necessary for an earlier kernel/gcc
>>configuration? (currently at 0.99.1, gcc2.3.3.. about to compile 0.99.4)
>>Is there some other problem that I have not noticed in everyday use?
There is a reason for the patch. Unfortunately the fix seems a bit
lacking. See below.
>>Thanks.
>
>>Kris
>
> I agree here. When I decided to compile 6.03 last week, I had no problems
> compiling or running it. I don't really understand why diffs were ever
> needed for this, as it worked fine for me from day 1.
>
> I went ahead and tested the current version with an ls -lR into a string of
> 8 pipes, and it works just fine.
>
> James
Tcsh has a timing problem that happens to some people and not to
others. It depends on the speed of the machine, what is currently in
the buffer cache, etc.
Example:
cat /etc/termcap | less
Here's what happens on my machine:
1) tcsh forks a process for cat and makes it the process group
leader
2) tcsh forks a process for less and adds it to the process group
3) tcsh goes to sleep
4) less gets scheduled (note the reverse order of scheduling!),
does execve(), tries do a tcsetattr() and gets stopped with
SIGTTOU (the tty is still owned by tcsh)
5) cat gets scheduled, takes control of the tty (too late now),
does execve() and blocks() on the pipe.
The end result is that the new job immediately gets stopped and has
to be restarted with fg, before it will run to completion.
I attempted to fix the problem with the supplied patch, but apparently
it isn't rigorous enough. The patch forces tcsh to sleep after forking
each child process, until the child signals (with SIGUSR1) that it is
ok to fork the next one. This should ensure that the children get
scheduled in the right order. The first process gets control of the
tty, before anyone else does execve() and everything is just dandy.
However, this doesn't seem to be working on slower machines (I have a
486DX/50).
On slow machines, the processes actually _do_ get scheduled in the
correct order, simply because tcsh doesn't have time to fork more than
one at a time. In fact, the first child gets scheduled before tcsh has
a chance to sigpause() on SIGUSR1. The end result here is that tcsh
sigpauses() after the fact and gets stuck. Sigh.
On reflection, I don't understand, why tcsh assumes that the process
group leader has to be the one to grab the tty. Any process in the
same session could set the tty process group, no?
The problem has been reported to me by one Ulrich Pegelow (Thanks! I
hope I got your name right.) and I have revised the patch so that it
should work for everyone. I will make a new version of tcsh available
this weekend. Some rarer (not linux specific) problems have also been
fixed.
If the unpatched tcsh works fine for you, by all means use it. It has
no truly crucial bugs. There are some problems, when you run out of
processes, but this never happens to most people.
Mika