[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Reworked input handling via read_socket_hook interface

From: Kim F. Storm
Subject: Reworked input handling via read_socket_hook interface
Date: 03 Mar 2004 15:33:11 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

[Repost -- I sent this to emacs-devel (aka. /dev/null) on Feb. 28]

Following my recent changes to read_avail_input that reduced the size
of the event buffer, a number of users reported aborts in the
read_socket_hook functions on X and W32, as these were not prepared
for the input event buffer to overflow.

To overcome the problems, I temporarily increased the buffer size.

The reason for reducing the size was that profiling had shown that the
initialization of the large buffer took a significant amount of CPU

I have now committed more radical changes in the interface to
read_socket_hook which I hope will fix this problem permanently.

Previously, the caller of read_socket_hook had to allocate a large
input_event buffer and initialize it before calling read_socket_hook,
and upon return, it had to call kbd_buffer_store_event on each event,
stopping after a quit_char event.

Now, the read_socket_hook functions use a single local input event to
process input, and immediately stores the event into the kbd_buffer
fifo via a new kbd_buffer_store_event_hold function.

The kbd_buffer_store_event_hold is similar to kbd_buffer_store_event,
but it treats quit events differently:
- it stores the quit event in a temporary event (via hold_quit arg),
- it discards further events stored after the quit event.

When read_socket_hook returns, the caller (e.g. read_avail_input)
stores the hold_quit event with kbd_buffer_store_event, which again
triggers the interrupt_signal.

I have modified all of the X, W32, and MAC versions, but I have only
tested on X and -nw on GNU/Linux, so there might be problems on W32
and MAC.  Please check and report any problems to me.

Kim F. Storm <address@hidden> http://www.cua.dk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]