Re: usr1-signal, usr2-signal, etc.

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 05 Dec 2006 23:51:03 +0100, address@hidden (Kim F. Storm) said:

> AFAICS, kbd_buffer_store_event[_hold] is usually called inside
> BLOCK_INPUT, but there may be a few places where this is not the
> case, notably in keyboard.c (and in the signal handler).

> Would someone pls. check [and fix] this??  One way could be to abort
> in kbd_buffer_store_event_hold if called without input blocked.

All indirect calls from (*read_socket_hook), Fx_file_dialog,
xmenu_show, or xdialog_show are inside BLOCK_INPUT.  But some calls
are not, because the current code (except handle_user_signal) assumes
that at most one signal handler will call kbd_buffer_store_event_hold
asynchronously, I think.

  * record_asynch_buffer_change either blocks SIGIO or stops polling
    before calling kbd_buffer_store_event_hold.

  * The remaining case is the calls from read_avail_input:

    - gobble_input -> read_avail_input:
      Like record_asynch_buffer_change above.

    - input_available_signal -> handle_async_input -> read_avail_input:
      Inside the SIGIO handler and not interrupted by the same signal.

    - Other handle_async_input -> read_avail_input:
      Inside #ifdef SYNC_INPUT.

    If polling used:

    - poll_for_input -> poll_for_input_1 -> read_avail_input:
      Inside the SIGALRM handler and not interrupted by the same signal.

    - x_make_frame_visible -> poll_for_input_1 -> read_avail_input:
      poll_suppress_count is set.

    - read_char -> kbd_buffer_get_event -> read_avail_input:
      After STOP_POLLING.

                                     YAMAMOTO Mitsuharu
                                address@hidden