[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-readline] Readline 6.2 regression vs. 6.1 on Mac OS X and perhaps e
From: |
Max Horn |
Subject: |
[Bug-readline] Readline 6.2 regression vs. 6.1 on Mac OS X and perhaps elsewhere |
Date: |
Mon, 25 Jun 2012 00:08:43 +0200 |
Dear GNU readline team,
I would like to report on an issue with readline 6.2 on Mac OS X 10.6.8 which
does not occur with 6.1 and older. I also have reports for this on 10.7 and
also on older Mac OS X systems.
To reproduce the issue,
1) compile the attached sample program (or any other program that sets
rl_event_hook),
2) run it inside Mac OS X' Terminal.app,
3) paste some text, e.g. this line.
What happens is that you can see the text slowly appear, character by
character, like in a bad sci-fi flick. Pressing any key will cause the
remaining text to appear instantly.
I traced this back to the change in input.c, in rl_read_key(), from 6.1 to 6.2.
You see, on Mac OS X, if you paste a string, then all characters are instantly
visible as input to the program. So, if you paste 50 chars, you will see 50
chars pending on stdin. Now when rl_event_hook is set, then rl_gather_tyi() is
used to read pending input. This function proceeds to read all 50 pending
characters at once. Previously, readline would then proceed to feed this input
to the program. Specifically, this is the old loop:
while (rl_event_hook && rl_get_char (&c) == 0)
{
(*rl_event_hook) ();
RL_CHECK_SIGNALS ();
if (rl_done) /* XXX - experimental */
return ('\n');
if (rl_gather_tyi () < 0) /* XXX - EIO */
{
rl_done = 1;
return ('\n');
}
}
But in 6.2, this was changed to the following:
while (rl_event_hook)
{
if (rl_gather_tyi () < 0) /* XXX - EIO */
{
rl_done = 1;
return ('\n');
}
RL_CHECK_SIGNALS ();
if (rl_get_char (&c) != 0)
break;
if (rl_done) /* XXX - experimental */
return ('\n');
(*rl_event_hook) ();
}
The effect being that now rl_gather_tyi is going to be called 50 times or so.
But only on the first time is there pending input. In the remaining calls,
there is no pending input, and hence the select() call runs into the 0.1 second
timeout. So it takes ~5 seconds for the pasted 50 characters to appear. Ouch.
For now, on my local system, I simply reverted to the old code. But I suppose
you guys had a good reason to change it in the first place... So I'd appreciate
if you could tell me what a "proper" fix for this might look like :-).
By the way, I personally observed this bug originally with the GAP computer
algebra system <http://www.gap-system.org/>, but found other mentions of it on
the net. E.g. ruby seems to be affected as well:
http://stackoverflow.com/questions/7296169/pasting-text-into-irb-is-incredibly-slow-readline-issue
http://stackoverflow.com/questions/5624740/rails-console-running-incredibly-slowly-when-editing-text
Cheers,
Max
minirl.c
Description: Binary data
- [Bug-readline] Readline 6.2 regression vs. 6.1 on Mac OS X and perhaps elsewhere,
Max Horn <=