I have checked, the problem is still present with Netscape 4.08.
(netscape-navigator-4.08-1.i386.rpm as distributed by Red Hat).
Further tracing reveals that the regular, high speed SIGALRM signals are
quite normal -- netscape receives them all the time. It sets a timer
requesting them every 50ms, though it only receives them every 70ms.
Netscape uses a pipe to queue single-byte tokens. The same process
reads and writes the pipe. In normal operation, only a few tokens go
into the pipe (about 1-40), and then the pipe is emptied (a byte at a
time).
Netscape keeps going through the cycle of writing tokens to the pipe in
bursts, then flushing the lot. This appears to be normal, as it also
does lots of other things in between bursts.
With kernel pre7, once I start downloading a file, this cycle keep going
but the number and size of write bursts before the read burst increases
a little at each cycle, until eventually so many tokens are written that
the pipe fills and the process blocks.
This is when Netscape stops working -- when the pipe fills up.
Netscape doesn't set the pipe to be non-blocking or anything. It could
use those SIGALRM calls to switch to the reading thread or whatever (who
knows what goes on in there), but it doesn't.
This looks like a Netscape bug. However it doesn't happen (for me) with
2.2.0-pre4. Someone else reported that it does happen for them with
other than pre7, and pre7 has fixed it for them. A few other people
haven't noticed the problem; a few more have seen it with 2.0.36.
The bug occurs much less often when I run netscape under `strace -tt -o
log', though it still occurs eventually. `strace -o log' is not so
effective. The is also some interaction with the X server, because if I
don't move the mouse (at all) or type anything after Netscape locks, it
recovers after about a second.
So I'm thinking it is a netscape bug, and something timing-related has
changed in recent kernels to trigger it on my machine.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/