Reworked input handling via read_socket_hook interface

Reworked input handling via read_socket_hook interface

[Kim F. Storm]

[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
cycles.


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 <storm@cua.dk> http://www.cua.dk

Re: Reworked input handling via read_socket_hook interface

[Harald Maier]

storm@cua.dk (Kim F. Storm) writes:

> 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.

FYI. I compiled the updated W32 version of emacs and all worked fine.

Harald

Re: Reworked input handling via read_socket_hook interface

[Juanma Barranquero]

On Mon, 08 Mar 2004 19:24:18 +0100
Harald Maier <harald@maierh.de> wrote:

> FYI. I compiled the updated W32 version of emacs and all worked fine.

Did you try configuring/bootstrapping?

I found out that PATH_BITMAPS isn't defined in nt/paths.h (so it isn't
in src/epaths.h).


                                                                Juanma

Re: Reworked input handling via read_socket_hook interface

[Jason Rumney]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> On Mon, 08 Mar 2004 19:24:18 +0100
> Harald Maier <harald@maierh.de> wrote:
> 
> > FYI. I compiled the updated W32 version of emacs and all worked fine.
> 
> Did you try configuring/bootstrapping?
> 
> I found out that PATH_BITMAPS isn't defined in nt/paths.h (so it isn't
> in src/epaths.h).

That was fixed on Thursday.

Re: Reworked input handling via read_socket_hook interface

[Juanma Barranquero]

On 13 Mar 2004 10:46:12 +0000, Jason Rumney <jasonr@gnu.org> wrote:

> That was fixed on Thursday.

Yeah, I know. The list isn't very responsive right now...

                                                           /L/e/k/t/u