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> | j...@suse.de back to ascii! __/ _---|____________\/
\ | 0911 74053-508 __/ (____/ /\
(/) | _____________________________/ _/ \_ vim:set sw=2 wm=8
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
