[SWIPL] weird readline lag after loading library(pce) on Mac OS X

Samer Abdallah samer.abdallah at eecs.qmul.ac.uk
Fri Jan 6 15:19:26 MET 2012


Hi Jan,
I've had a look into this (subsequent to our private email)
and come to the conclusion that it's a bug in readline and nothing
to do with SWI's readline code. Even compiling the example
program rlevent.c that comes with readline 6.2 (Macports) I
get the same behaviour. It's nothing to do with how long rl_event_hook
takes to execute. 

I also tried compiling the test program against
readline 5 and the problem *doesn't* appear - it
works fine, *but*, in this case, the execution time of rl_event_hook
does make a difference - if rl_event_hook takes a while to execute, 
then that much lag appears in the keyboard response (even for
ordinary keys) - 10ms or 20ms delay is no problem but 100ms makes it 
unusable. 

So, one possible fix (untested) is to compile SWI against readline 5, which is
in Macports. Are there any features that will be lost by doing this?

I've also had a look into the readline 6.2 source code and discovered that
the keyboard response lag is directly related to the _keyboard_input_timeout
variable in input.c. This is used only in two places, in both cases, in a 
call to select. This is where I give up for now! But at least a temporary
work around is to set a lower timeout - around 20ms seems to be ok,
which means that rl_event_hook will be called at most at 50Hz. This seems
to be ok on my system - idle CPU usage is at around 0.1%.

Samer.




On 18 Dec 2011, at 09:43, Jan Wielemaker wrote:

> Hi Samer,
> 
> On 12/17/2011 07:48 PM, Samer Abdallah wrote:
>> greetings all,
>> I've been getting this weird readline behaviour for a while now (on
>> Snow Leopard as well my recent builds on Lion) where there is about
>> 1/3 second lag between pressing left or right cursor keys and cursor
>> movement, but only after loading library(pce). For example, start typing
>> some goal at the swipl prompt, press and hold the left cursor - I see a 1/3 s
>> lag before movement begins - then aim to stop at some particular character -
>> my cursor goes one extra character 1/3 second after I release the key.
>> This amounts to a mild irritation, but it's cumulative, and it's reached the
>> point where I can be bothered to try to fix it, but have no idea where to start.
>> What could the problem be? libreadline?  tty settings? And why does it only
>> occur after loading library(pce)?  Does anyone else observe this?
> 
> This seems mostly a MacOS issue. The other version of this is a paste
> operation, where the characters appear on-by-one. B.t.w., you can type a
> character yourself to speedup the process. The latter sometimes happens
> on Linux as well (but in my experience rarely, while it is almost normal
> on the Mac). Its been going on for a long time and it seems that the
> exact readline version is irrelevant.
> 
> The readline/xpce interaction works by means of the readline event hook,
> which calls event_hook() in src/os/pl-rl.c. In this file you find most
> of the stuff. From there, the call goes through a long chain of hooks,
> for which I describe what should happen in the normal Unix/X11 setup.
> 
> event_hook() calls PL_dispatch() (defined in pl-fli.c). This calls
> pce_dispatch() in packages/xpce/swipl/interface.c. Then it goes to
> packages/xpce/src/itf/interface.c, pceDispatch(). Here you see two
> scenarios: (1) the display is opened (first branch) and (2), the display
> is not yet opened. In the normal setup, with the display opened, this
> will call dispatch_events() in packages/xpce/src/win/displaymgr.c, which
> (on Unix) calls packages/xpce/src/x11/xevent.c, ws_dispatch() that does
> its tricky stuff with the X11 event-loop.
> 
> I guess you should put some print statements at various places that
> included precise timing info to get a clue.  I think you'll make friends
> by fixing that :-)
> 
> 	Cheers --- Jan



More information about the SWI-Prolog mailing list