Very Computer

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
>TCP/IP.

>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?

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.