Sorry to revive a three-month-old thread. Juergen, I'm not following what the alarm() gives us over a nonblock with a sufficiently high value. Don't _both_ cases result in loss to the scrollback? If it's just the Msg() thing, we could make that the normal behavior for nonblock, too... Maybe I just don't properly understand how nonblock works?
As to the CTRL-C thing you bring up, I wonder how much that has to do with blocking vs nonblocking, as opposed to using read()/write() on each waiting source/sink before coming back around to do another read() or write(). I mean, assuming only blocking reads, after we fill up our buffer, if we went on to check other sources, wouldn't we then find the user's C-c before we pulled more output from the child pty? (Again, my understanding of screen's I/O processes still leave much to be desired, so feel free to educate me on anything I'm apparently clueless of). Thanks very much for your time, -mjc Juergen Weigert wrote: > Uh, > difficult matter.... > > In case of a slow line, e.g. dialup line (bandwidth) or overloaded line > (high latency) we'd like screen to wait a bit and try to get the display > right. > > It is also an annoyance to users, when the scrollback buffer of their > xterm/konsole/gnome-terminal does not contain *all* text. > This requires 'nonblock off'. > > (On the other hand: > The current full blocking default also has the downside that as soon as an > application becomes I/O-bound, screen becomes quite nonresponsive. > $ cat hugefile > CTRL-C > CTRL-C > ... > may be difficult to interrupt. > ) > > I believe that nonblock is not the correct solution for fixing > hung write() calls. > > I'd suggest screen should have an alarm() over each write() > and switch to nonblock, when the alarm() fires. > With a prominent Msg() saying so, as soon as the display works again. > > cheers, > JW- > > > On Mar 05, 09 23:17:42 -0800, Micah Cowan wrote: > Does anyone know, is there any particular reason why we don't make > nonblock the default? It's an annoyance to users when a display gets > hung and any windows connected with it get stuck, especially since > novice users are unlikely to realize that "nonblock 1" won't affect the > buggered display, and may not think to do C-a : at % nonblock on > > I'd like to propose that the default value for defnonblock be changed > from "off" to something like, I dunno, 8 ? Or lower, if there's no > particular reason why we shouldn't. > >> >> -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. Maintainer of GNU Wget and GNU Teseq http://micah.cowan.name/
