Should read of pty block when no one has opened tty?

Should read of pty block when no one has opened tty?

Post by Terry Lambe » Fri, 01 May 1992 08:42:49

Quote:>We are trying to port some locally developed software from one
>hardware platform to another and the pseudo-ttys behave differently
>and we don't know what is "normal".

>Our old platform is a Unisys 7000/40 which is Berkeley-based.
>The new platform is a VAX 6410 running System V 3.1c with LAI

>On the old platform, we have a program that is a front-end to
>rlogin.  It opens the master side of a pseudo-tty and waits for
>some process to open the slave side (a uucp cu-like program which
>is part of a canned application we run from Bellcore).  When that
>process does open the slave side, it tells our front-end which
>system it wants to connect to on a TCP ethernet and our front-end
>fork/execs rlogin with the appropriate arguments.

>When it opens the master side and does the first read(), it blocks
>until another process opens the slave side and writes something
>from its end.

>On the VAX, when we open the master side, if no one has opened the
>slave side, we do not block.  select() thinks that there are
>characters ready to read and returns an endless stream of -1's.

>When a process on the slave side has opened its side, reads from
>the master side properly block.

>What is correct?  It seems to us that the VAX/LAI implementation
>doesn't make sense.  How would we convince Digital/LAI that some-
>thing is wrong with the way they've implemented pseudo-tty's?
>Is this a known problem with a readily available fix?

You have three problems:

1)      The return value of -1 from select() is an indicator of an
        error condition, not an indication of data being available.
        Generally, this is "interrupted by signal".

2)      There appears to be a single read/write queue for kernel
        sleeps for queued reads and writes.  What this means is
        that if you queue a read and then do a write to the same
        channel, the write does not complete until the read has
        completed.  This is the problem with the "Multidrop" I/O
        boards for boxes like the Altos 2000.  If you have this
        problem, the only soloution is a rewrite of the offending
        driver to allow writes to complete during an incomplete
        (kernel slept) read operation.

3)      LAI TCP/IP has a notorious problem with select(), in that
        it was not an initial kernel call.  As such, many things,
        such as pty and tty drivers and FIFO's do not support a
        select call on their file descriptor.  The soloution is
        to, once again, rewrite the offending driver.  You may, on
        some version of SVr3 be able to use poll() instead, but it
        may not be supported by LAI.  From recollection, I believe
        that this was not supported until SVr3.2.  SCO had a similar
        problem with their stuff until Steph there fixed it.  Old
        versions of ODT required that you use XSelect() or poll()
        rather than select if you wanted to loop-unroll XtMainAppLoop()
        from the X tool kit to wire in network event processing,
        since XtAddInputHandler() didn't work correctly with FIFO's.

                                        Terry Lambert

Disclaimer: Any opinions in this posting are my own and should not be
construed to represent those of either present or former employers.


1. How do I open a pty/tty pair?

I cannot seem to figure out the proper sequence for opening pty/tty pairs.
I wish to have two processes (a parent and a child) communicating through
a pty/tty pair, with the child process having the tty as it's controlling

I have tried this:

1. parent tries to open a pty, and repeats until it succeeds.
2. parent tries to open corresponding tty, and goes back to step 1 on failure.
3. parent forks.
4. parent closes tty. child closes pty.
5. parent and child communicate through pty/tty pair.

Unfortunately, this method won't allow the child to make itself the leader
of a new session with the newly-opened tty as it's controlling terminal.

I have tried this:

1. parent tries to open a pty, and repeats until it succeeds.
2. parent forks.
3. child closes pty.
4. child performs setsid().
5. child opens tty.
6. parent and child communicate through pty/tty pair.

Unfortunately, if the open of the tty fails, then there is no simple way for
the child to inform the parent of this.


- Josh

2. Good Unix term program?

3. Problem with blocking opens preventing non-blocking opens in AIX 5.2

4. Stingray 128/3d and XF86 3.1.2

5. read() and tty/pty

6. Saving Crontabs

7. Non-Block read & Block read

8. How do I download the complete Red Hat distribution?

9. Non blocking socket blocks; says 'read would block' ?

10. Software to read NOS/VE backup tapes

11. - can one change tty modes for tty not stdio ?

12. HELP: Read not blocking on open socket.

13. tty-less processes with tty's open