Hi all!
Sorry if this is a wrong forum for this sort of mail. I just
did not know any other forum that might have been a better match.
I tried using select() to test a pty master for readiness for
writing. If done twice without any I/O in between the calls
to select() the latter one blocked even when the timeout value
was specified as a timeval {0, 0}.
Even when it did not block the pty master seemed to be willing
to receive input until the pty buffer overflowed (the first
call to select()).
Test e.g.
socket localhost chargen | testprog
to see overflowed input being dropped. The 'testprog' should be
a process opening a pty and forking a child process to read the
pty slave and echo everything back.
I am sort of puzzled about this. Should the write test using
select() work at all for a pty master? If it should work, it
actually might not - apparently. And if it should not, what
is the point?
I cannot see any obvious reason why the pty master were somehow
a special case among different communication devices like pipes
and sockets in this respect.
As far as I can tell the following quote from the termios manual
page implies that it has probably been intentional that there is
no way to know in advance when there is space in the downstream
buffer of the pty.
<quote>
Each terminal device file has associated with it an input queue, into
which incoming data is stored by the system before being read by a pro-
cess. The system imposes a limit, {MAX_INPUT}, on the number of bytes
that may be stored in the input queue. The behavior of the system when
this limit is exceeded depends on the setting of the IMAXBEL flag in the
termios c_iflag. If this flag is set, the terminal is sent an ASCII BEL
character each time a character is received while the input queue is
full. Otherwise, the input queue is flushed upon receiving the charac-
ter.
</quote>
I think the pseudo terminal master would benefit from an input
option to make it correctly report it's writeability status
instead of simply flushing the clist.
If the above mentioned IMAXBEL should do exactly this, it is
my current belief that then the select() call does not properly
report the true status, because non-blocking writes still seem
to return errno == EAGAIN ("resource temporarily unavailable"),
though the select() call with zero timeout might block.
Even the TIOCOUTQ ioctl() seems not to be much of help when
trying to find out whether the downward pty buffer might have
any space available because it persistently returns 0.
Apparently it works for the upstream buffer only. So, some
other alternative way to avoid overflowing the downward pty
buffer would be very useful.
Cheers,
// jau
.--- ..- -.- -.- .- .- .-.-.- ..- -.- -.- --- -. . -.
/ Jukka A. Ukkonen, Mawit Ltd, Finland
/__ M.Sc. (sw-eng & cs) (Phone) +358-400-606-671
/ Internet: [EMAIL PROTECTED] (Home) +358-9-6215-280
/ Internet: [EMAIL PROTECTED]
v Internet: [EMAIL PROTECTED]
+ + + + My opinions are mine and mine alone, not my employers. + + + +
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
