[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-readline] Problem with CTRL-z and readline()
From: |
Chet Ramey |
Subject: |
Re: [Bug-readline] Problem with CTRL-z and readline() |
Date: |
Wed, 04 Mar 2015 21:49:38 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
On 3/2/15 9:29 AM, Dave Wysochanski wrote:
> I agree this is what is happening - the signal handler loops around
> pathologically trying the same operation and getting the same result.
> Can you explain why the problem is intermittent? I can reproduce it but
> not always.
It's a race condition: if the kernel schedules the interactive shell that
called the script first and it catches the signal, it will change the
terminal's process group back to its own and put the program using
readline into a background process group before it even gets a chance to
handle the signal. Once it handles the signal, anything it does that
touches the terminal -- since it's in a background process group -- will
generate a SIGTTOU.
>> There are a couple of things that can be done here. The first is removing
>> the shell from the equation. Changing `rl' to `exec rl' seems to eliminate
>> the problem behavior. (The shell doesn't matter: running it from dash
>> does the same thing with and without the `exec'.) That makes me wonder
>> whether the difference is whether or not the process using readline is the
>> process group leader, but I can't figure out why that would make the
>> difference.
>>
>> Obviously, preventing readline from trying to restore the terminal settings
>> will solve this problem, but that's a little drastic: any program using
>> readline will then leave the terminal settings modified on SIGTSTP, which
>> will cause havoc for users of shells who don't restore the terminal
>> settings when a process stops or terminates due to a signal.
>>
>> I will have to look at some other things. Any ideas are welcome.
>>
>
> Not knowing much about this code, but just looking at a high-level view
> of software behavior, it does seem like a signal handler problem.
> Though not sure what it would take to fix it without introducing
> undesired side-effects as you describe or otherwise.
It seems like the thing to do in this case is to prevent the SIGTTOU from
being generated at all. The process can block or ignore it; I will have
to play around with it and see if that can work.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/