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

[Juergen Weigert]

On Jun 30, 09 12:41:04 -0700, Micah Cowan wrote:
> 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. 

You are right. I was under impression that nonblock is a boolean.
Actually nonblock also allows us to specify a timeout.
This is exactly what I was looking for!

> 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?

When I suggested alarm(), I quickly browsed the code, and saw several calls
to write(), that were not guarded with any timeout. So I wonder, how this
nonblock timeout could work in case of write syscall not returning....

        cheers,
                JW-

> 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).

The question about CTRL-C is this:
- it either gets converted to SIGINT at the terminal driver, the momment
  the user presses the key.
- or it is sent inband as a '\003' character.
Screen does the latter, I believe.
In that case, building up a buffer of non read data becomes problematic, as
this unread buffer may contain characters a user would have expected to be
handled out of band.

        cheers,
                JW-

> 
> 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/
> 
> 

-- 
 o \  Juergen Weigert  paint it green!    __/ _=======.=======_
<V> | address@hidden       back to ascii!  __/        _---|____________\/
 \  | 0911 74053-508                __/          (____/            /\
(/) | _____________________________/              _/ \_ vim:set sw=2 wm=8
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)