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

[storm@cua.dk (Kim F. Storm)]

Thank you very much for the analysis.

Could you please try to fix the problematic cases?


YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Tue, 05 Dec 2006 23:51:03 +0100, storm@cua.dk (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
> 				mituharu@math.s.chiba-u.ac.jp
>
>

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk