This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: known issues with current dll
Hi!
Saturday, 17 March, 2001 Christopher Faylor cgf@redhat.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@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19