Next: Specifics About the Emacs Event, Previous: Main Loop, Up: Events and the Event Loop [Contents][Index]
Here is an approximate diagram of the collection processes at work in SXEmacs, under TTY’s (TTY’s are simpler than X so we’ll look at this first):
asynch. asynch. asynch. asynch. [Collectors in
kbd events kbd events process process the OS]
| | output output
| | | |
| | | | SIGINT, [signal handlers
| | | | SIGQUIT, in SXEmacs]
V V V V SIGWINCH,
file file file file SIGALRM
desc. desc. desc. desc. |
(TTY) (TTY) (pipe) (pipe) |
| | | | fake timeouts
| | | | file |
| | | | desc. |
| | | | (pipe) |
| | | | | |
| | | | | |
| | | | | |
V V V V V V
------>-----------<----------------<----------------
|
|
| [collected using select() in emacs_tty_next_event()
| and converted to the appropriate Emacs event]
|
|
V (above this line is TTY-specific)
Emacs -----------------------------------------------
event (below this line is the generic event mechanism)
|
|
was there if not, call
a SIGINT? emacs_tty_next_event()
| |
| |
| |
V V
--->------<----
|
| [collected in event_stream_next_event();
| SIGINT is converted using maybe_read_quit_event()]
V
Emacs
event
|
\---->------>----- maybe_kbd_translate() ---->---\
|
|
|
command event queue |
if not from command
(contains events that were event queue, call
read earlier but not processed, event_stream_next_event()
typically when waiting in a |
sit-for, sleep-for, etc. for |
a particular event to be received) |
| |
| |
V V
---->------------------------------------<----
|
| [collected in
| next_event_internal()]
|
unread- unread- event from |
command- command- keyboard else, call
events event macro next_event_internal()
| | | |
| | | |
| | | |
V V V V
--------->----------------------<------------
|
| [collected in `next-event', which may loop
| more than once if the event it gets is on
| a dead frame, device, etc.]
|
|
V
feed into top-level event loop,
which repeatedly calls `next-event'
and then dispatches the event
using `dispatch-event'
Notice the separation between TTY-specific and generic event mechanism. When using the Xt-based event loop, the TTY-specific stuff is replaced but the rest stays the same.
It’s also important to realize that only one different kind of system-specific event loop can be operating at a time, and must be able to receive all kinds of events simultaneously. For the two existing event loops (implemented in event-tty.c and event-Xt.c, respectively), the TTY event loop only handles TTY consoles, while the Xt event loop handles both TTY and X consoles. This situation is different from all of the output handlers, where you simply have one per console type.
Here’s the Xt Event Loop Diagram (notice that below a certain point, it’s the same as the above diagram):
asynch. asynch. asynch. asynch. [Collectors in
kbd kbd process process the OS]
events events output output
| | | |
| | | | asynch. asynch. [Collectors in the
| | | | X X OS and X Window System]
| | | | events events
| | | | | |
| | | | | |
| | | | | | SIGINT, [signal handlers
| | | | | | SIGQUIT, in SXEmacs]
| | | | | | SIGWINCH,
| | | | | | SIGALRM
| | | | | | |
| | | | | | |
| | | | | | | timeouts
| | | | | | | |
| | | | | | | |
| | | | | | V |
V V V V V V fake |
file file file file file file file |
desc. desc. desc. desc. desc. desc. desc. |
(TTY) (TTY) (pipe) (pipe) (socket) (socket) (pipe) |
| | | | | | | |
| | | | | | | |
| | | | | | | |
V V V V V V V V
--->----------------------------------------<---------<------
| | |
| | |[collected using select() in
| | | _XtWaitForSomething(), called
| | | from XtAppProcessEvent(), called
| | | in emacs_Xt_next_event();
| | | dispatched to various callbacks]
| | |
| | |
emacs_Xt_ p_s_callback(), | [popup_selection_callback]
event_handler() x_u_v_s_callback(),| [x_update_vertical_scrollbar_
| x_u_h_s_callback(),| callback]
| search_callback() | [x_update_horizontal_scrollbar_
| | | callback]
| | |
| | |
enqueue_Xt_ signal_special_ |
dispatch_event() Xt_user_event() |
[maybe multiple | |
times, maybe 0 | |
times] | |
| enqueue_Xt_ |
| dispatch_event() |
| | |
| | |
V V |
-->----------<-- |
| |
| |
dispatch Xt_what_callback()
event sets flags
queue |
| |
| |
| |
| |
---->-----------<--------
|
|
| [collected and converted as appropriate in
| emacs_Xt_next_event()]
|
|
V (above this line is Xt-specific)
Emacs ------------------------------------------------
event (below this line is the generic event mechanism)
|
|
was there if not, call
a SIGINT? emacs_Xt_next_event()
| |
| |
| |
V V
--->-------<----
|
| [collected in event_stream_next_event();
| SIGINT is converted using maybe_read_quit_event()]
V
Emacs
event
|
\---->------>----- maybe_kbd_translate() -->-----\
|
|
|
command event queue |
if not from command
(contains events that were event queue, call
read earlier but not processed, event_stream_next_event()
typically when waiting in a |
sit-for, sleep-for, etc. for |
a particular event to be received) |
| |
| |
V V
---->----------------------------------<------
|
| [collected in
| next_event_internal()]
|
unread- unread- event from |
command- command- keyboard else, call
events event macro next_event_internal()
| | | |
| | | |
| | | |
V V V V
--------->----------------------<------------
|
| [collected in `next-event', which may loop
| more than once if the event it gets is on
| a dead frame, device, etc.]
|
|
V
feed into top-level event loop,
which repeatedly calls `next-event'
and then dispatches the event
using `dispatch-event'
Next: Specifics About the Emacs Event, Previous: Main Loop, Up: Events and the Event Loop [Contents][Index]