screen-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Micah Cowan
Subject: Re: [screen-devel] Why not nonblock by default?
Date: Wed, 01 Jul 2009 09:26:11 -0700
User-agent: Thunderbird 2.0.0.22 (X11/20090608)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Juergen Weigert wrote:
> 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!

So, does this mean you approve of setting nonblock to something like,
say, 5-10 seconds by default? The main problem I want to avoid, is that
once a display gets locked up (perhaps it's inflooping?), there's no way
to set that display's nonblock, since the attempt will try to contact
the attacher again :\

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

Yeah, good point. At some point we should check through the code to make
sure that everything obeys the nonblock setting.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpLjiIACgkQ7M8hyUobTrHMuwCghB5Doz+gbFB7VUd03jh4rLn/
QpoAni9NE1RUsFZZh5sS80j3K6p9CicK
=o23v
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]