Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Sat, 17 Mar 2001 16:05:36 +0300 From: Egor Duda X-Mailer: The Bat! (v1.45) Personal Reply-To: Egor Duda Organization: DEO X-Priority: 3 (Normal) Message-ID: <19889636700.20010317160536@logos-m.ru> To: Christopher Faylor CC: cygwin-developers AT cygwin DOT com Subject: Re: known issues with current dll In-reply-To: <20010316211721.A3489@redhat.com> References: <5627632543 DOT 20010316225211 AT logos-m DOT ru> <20010316163702 DOT A22471 AT redhat DOT com> <20010316164626 DOT A22656 AT redhat DOT com> <20010316211721 DOT A3489 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Saturday, 17 March, 2001 Christopher Faylor cgf AT redhat DOT com wrote: CF> On Fri, Mar 16, 2001 at 04:46:26PM -0500, Christopher Faylor wrote: >>On Fri, Mar 16, 2001 at 04:37:02PM -0500, Christopher Faylor wrote: >>>On Fri, Mar 16, 2001 at 10:52:11PM +0300, Egor Duda wrote: >>>> my recent tty changes broke ^D (eof) in sh.exe and ^Z (suspend) in >>>>bash.exe. i've tracked them down and now figuring a way to fix it. >>>>i'll post a patch when it's ready. >>> >>>I do see the CTRL-D problem but CTRL-Z is working ok for me in both >>>CYGWIN=tty and CYGWIN=notty modes. >>> >>>CTRL-Z does not interrupt a running process with CYGWIN=notty but it >>>has never done that. It only works when a cygwin process is waiting >>>for input. >>> >>>CTRL-Z does interrupt a process at any time when CYGWIN=tty. >> >>Nevermind. I see now it is broken. I just fixed this behavior recently, >>fwiw. It's back to the way that it used to work. CF> This looked so much like the problem that I'd had before, that I thought I CF> should take a look at it. CF> There was a race beteen EOF and signal processing. When the parent pty CF> sent a signal, it also essentially sent an EOF. So, it was a race in CF> the child as to which was processed. This may well have been a problem CF> with my previous code, too. CF> I checked in a fix. I hope. yes, we shouldn't send eof when signal was received. i also think that we should eat_readahead (-1), when user sends signal, at least on linux signal empties current buffer (i didn't find such requirement in SUSv2, though). to solve ctrl-D problem i see 2 ways -- either return to the old scheme, when master sends dummy buffer to slave via pipe on eof, or tweak ready_to_read stuff for fhandler_tty_slave, so it will react when input_available_event is signalled, not when pipe handle does. currently, i'm trying to do the latter. Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19