Current-Users archive

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

Re: problems using a pty

On Fri, Feb 12, 2010 at 09:43:05AM -0800, Brian Buhrow wrote:
>       Hello.  What wait channel is the slave process waiting on? 


> Can you
> try this test on a 4.x system? 

Well, after installing qemu from pkgsrc and doing an install, yes.  I
observe the same problem on a 4.x system.

> .  If you test on a 4.x system and it works, then it's a bug in
> the pty code, if not, then it's probably something in your test.

Well, the following things puzzle me.. I won't rule out me doing
something wrong but:

1) without a call to cbreak() things work fine
2) if I take my section of test code, wrap a main(){} around it, build
   and run that then things work as the should.
3) why is an ioctl on the slave stdin affecting other file
   descriptors?  If I do a ktruss on the slave using a wrapper script
   then I can see that:
        a) read returns immediately with 0 bytes read when it should
           wait for a character.
        b) the slave is writing to the pipe back to the director but a
           poll() on the director side of that same pipe says there is
           no data to read.... without cbreak() there is data to read
           - I know this because the director polls the pipe fd before
           it reads to avoid blocking when the slave either dies or
           does not return output when it should.  Without cbreak()
           the whole poll/read data thing happens fine.
        c) writes to a slave debug dribble file stop as well, after every
           write I fflush the file handle so data should be written
           but the writes seem to stop after the cbreak() call.  In
           the kdump output I can see write being called on the file

> Just my thoughts.

thanks they were appreciated :)

Brett Lymn
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."

Home | Main Index | Thread Index | Old Index