bug-hurd
[Top][All Lists]
Advanced

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

term bugs


From: Marcus Brinkmann
Subject: term bugs
Date: Mon, 2 Sep 2002 13:46:11 +0200
User-agent: Mutt/1.4i

Hi,

I have run the Perl IO:TTy module's tests.

=========================================================================
Checking basic functionality and how your ptys handle large strings...
  This test may hang on certain systems, even though it is protected
  by alarm().  If the counter stops, try Ctrl-C, the test should continue.

trying getpt()...
trying grantpt()...
trying unlockpt()...
trying ptsname_r()...
trying to open /dev/ttyp1...
isatty($master): NO
=========================================================================

I don't know if this is a problem or not.  isatty should return if the file
descriptor is associated with a terminal device, but is the master a
terminal device in that sense?  Linux returns YES.

=========================================================================
isatty($slave): YES
Child PID = 2976
TIMEOUT(SIGALRM) at test.pl line 187.

WARNING: your raw ptys block when sending more than 300 bytes!
This may cause problems under special scenarios, but you probably
will never encounter that problem.

ok 4
=========================================================================

This is exactly the same problem as when doing a cut & paste of more than
300 bytes in screen.  We really should fix that, as all other sane systems
allow at least 512 bytes.  This is obviously related to the 300 byte hi
watermark in term, but I am not sure if the 300 byte queue should work
anyway.  When the writer goes to sleep, it first wakes up the reader with
bottom->start_output, should that do the job already?  I am a bit unsure how
the code is supposed to work.

The limit in Linux seems to be 8061, after that it blocks.  The test suite
expects to be able to send 512 bytes without blocking, so it seems that just
increasing the watermark should be ok.  On the other hand, being able to
handle a screen full (like 2000 bytes) in screen or even more is very
helpful.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/




reply via email to

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