Re: Sockets and PTYs

On Tue, Apr 27, 2004 at 03:51:07PM +0200, Frank Gie=DFler wrote:
> Hi,
>=20
> I hope there is someone present on this list. It looks like newer TCP/I=
P=20
> versions (beginning with around 4.2) at least partly break EMX support=20
> for xf86sup. After a socket is created, PTYs can't be opened any more.=20
> The attached code illustrates this. I first opens a PTY, then creates a=
=20
> socket, and then tries to open another PTY, which fails. I don't really=
=20
> know how the TCP/IP version can be causing this. The output of the=20
> program is:
>=20
> [E:\x11_latest\xf86sup\example]socketpty
> Successfully opened \dev\ptyp0, handle =3D5
> Socket created, handle =3D 6
> Cannot open pty \dev\ptyp1, errno =3D 5 (I/O error)
>=20
> Any ideas, anybody?

The PTY support in xf86sup.sys is entirely unrelated to TCP/IP (should=20
be :-) ). It is a set of devices which form some kind of artificial pipe=20
connection between the master and the slave pty. The pipe buffer is kept
in allocated memory of the device driver. The purpose of this constructio=
n
is to have real CHAR devices as in Unix PTYs. Replacing this with ordinar=
y
DosPipe's would fail in case a process expects a character device,
such as in a command pipeline like 'ls | more': more does isatty() on
stdin and will behave differently if stdin is connected to a pipe or file=
 or
a character device. All in all it is some kludge to get xterm behave=20
compatible to Unix xterm even in case of a CMD.EXE shell.

I have absolutely no idea how a newer TCP version would come into play
here other than a possible (I doubt so) name clash where TCP/IP would its=
elf
try to fake PTY/TTY devices. But then EMX should not know about, as it
explicitly deals with the devices /dev/ptyp* and /dev/ttyp*.

I rather suspect a long existing bug in xf86sup.sys that in rare situatio=
ns
refuses to open another PTY even if it is still present and unblocked. Bu=
t I
haven't found that bug for years so far. Might be some race condition?

Holger