Re: problems using a pty

[Brett Lymn <blymn%baesystems.com.au@localhost>]

On Fri, Feb 19, 2010 at 09:14:57AM -0800, Brian Buhrow wrote:
>       Hello.  More questions.  
> 

More answers... I do have things working now but just for posterity :)

> 1.  Are you using the functions in libcurses(3) to manipulate the terminal
> or are you using terminal ioctls directly to do it?  If I do a man cbreak I
> get a function in the libcurses library, but I know you can use ioctls or
> the stty(1) command to do the same thing.  If you're using curses, and you
> do it with ioctls directly, does the behavior change when you switch modes?
> 

I would not expect so since the cbreak() call just does the ioctl()
call with some curses house keeping.  I did dump out the termios
settings before and after the cbreak() call and all the flags
etc. looked sane.

> 2.  If you use select(2) rather than poll(2) do you get the same behavior?
> 

select(2) is deprecated.

> 3.  If things work before you call cbreak() but break after you call it, do
> they work again after you call nocbreak(), assuming you're using the
> currses interface?
>

Nope - if I call nocbreak() things don't magically start working.
 
>       I'm wondering if this is either a bug in poll(2) or a bug in
> curses(3).
> 

Well, the code I am working on is supposed to test for bugs in curses
but I didn't expect to be seeing any this unsubtle...

Anyway, your question about the waitchannel was the trigger to solving
this.  I have found that when I drain the output on the pty from the
slave then everything unjams.  It seems like the writes are getting
blocked for every fd though - I guess when cbreak() is called the
buffering on the output is turned off too so stdio is blocking further
writes to the pty until the direct drains the data.  I do find it very
odd that all the file descriptors are then blocked, ktruss claims that
data is written to the various file descriptors on the slave side but
no data shows up on any of the file descriptors on the director side
until the director reads from the pty.  Rather odd but I can work with
that.

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."