Re: PATCH: Zpty cleanup (merge 13061 with 13116)

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Bart Schaefer wrote:

> ...
> 
> > There were some things in [read_poll()] I think were really wrong,
> > like testing `select() > 1' and like trying all possible tests if the
> > first tests worked but returned zero.
> 
> ...
> 
> However, that does not mean that the rest of the tests should be skipped
> when select() returns 0.  A return of 0 means the select() timed out,
> which (apparently) might happen under Cygwin even if there actually are
> characters available to be read.  Peter/Andrej, is that the case?

I don't know about Cygwin, but that blocking read (line 1381) is
exactly the test I wanted to avoid. When building the patch I had a
case where zpty was waiting in checkptycmd() because of that (select()
correctly had returned zero, saying that there wasn't anything to be
read, the `timeout' being zero after all means that the select should
just do a poll, not wait).

I don't know if I can reproduce it, maybe I'll try at the weekend.

> ...
> 
> [Late-breaking note:  *Somebody* should have noticed that read_poll()
> calls gettyinfo() and settyinfo(), which of course affects SHTTY, and
> has nothing whatever to do with the pty.  So polltty=1 is just a very
> expensive no-op for zpty, and it really must pass 0.]

Ahem. Oops.

Hmhm. I wasn't too happy with calling read_poll() in zpty.c
anyway. The problem I wanted to solve is, of course, that a zpty
command should be marked as `finished' if there is still input to be
read even though the OS tells us that the process has exited (which
can happen and is very ugly).

I don't have any particular comments or patches for the other things. Yet.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de