From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23607 invoked from network); 8 Nov 2000 10:20:32 -0000 Received: from sunsite.dk (HELO sunsite.auc.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 Nov 2000 10:20:32 -0000 Received: (qmail 2606 invoked by alias); 8 Nov 2000 10:20:26 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13132 Received: (qmail 2599 invoked from network); 8 Nov 2000 10:20:25 -0000 Date: Wed, 8 Nov 2000 11:20:23 +0100 (MET) Message-Id: <200011081020.LAA20686@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Sun, 5 Nov 2000 09:12:02 +0000 Subject: Re: PATCH: Zpty cleanup (merge 13061 with 13116) 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