Re: [screen-devel] Why not nonblock by default?

[Micah Cowan]

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/