[doc]/gui/windowing-overview.html#(part._espacethreads) dove continuo a copiare da qui.
Eventspaces e threads
When a new eventspace is created, a corresponding handler thread is created for the eventspace. When the system dispatches an event for an eventspace, it always does so in the eventspace’s handler thread. A handler procedure can create new threads that run indefinitely, but as long as the handler thread is running a handler procedure, no new events can be dispatched for the corresponding eventspace.
When a handler thread shows a dialog, the dialog’s
show method implicitly calls
yield for as long as the dialog is shown. When a non-handler thread shows a dialog, the non-handler thread simply blocks until the dialog is dismissed. Calling
yield with no arguments from a non-handler thread has no effect. Calling
yield with a semaphore from a non-handler thread is equivalent to calling
Creare e settare l’eventspace
Whenever a frame, dialog, or timer is created, it is associated with the current eventspace as determined by the
current-eventspace parameter (see Parameters [
make-eventspace procedure creates a new eventspace. The following example creates a new eventspace and a new frame in the eventspace (the
parameterize syntactic form temporary sets a parameter value):
(let ([new-es (make-eventspace)]) (parameterize ([current-eventspace new-es]) (new frame% [label "Example"])))
When an eventspace is created, it is placed under the management of the current custodian. When a custodian shuts down an eventspace, all frames and dialogs associated with the eventspace are destroyed (without calling
top-level-window<%>), all timers in the eventspace are stopped, and all enqueued callbacks are removed. Attempting to create a new window, timer, or explicitly queued event in a shut-down eventspace raises the
An eventspace is a synchronizable event [
[doc]/reference/sync.html#(tech._synchronizable._event)] (not to be confused with a GUI event), so it can be used with
sync. As a synchronizable event, an eventspace is in a blocking state when a frame is visible, a timer is active, a callback is queued, or a
menu-bar% is created with a
'root parent. (Note that the blocking state of an eventspace is unrelated to whether an event is ready for dispatching.)
Continuations e gestione dell’evento
Whenever the system dispatches an event, the call to the handler is wrapped with a continuation prompt (see
[doc]/reference/cont.html#(def._((quote._~23~25kernel)._call-with-continuation-prompt))]) that delimits continuation aborts (such as when an exception is raised) and continuations captured by the handler. The delimited continuation prompt is installed outside the call to the event dispatch handler, so any captured continuation includes the invocation of the event dispatch handler.
For example, if a button callback raises an exception, than the abort performed by the default exception handler returns to the event-dispatch point, rather than terminating the program or escaping past an enclosing
with-handlers wraps a
(yield) that leads to an exception raised by a button callback, however, the exception can be captured by the
Along similar lines, if a button callback captures a continuation (using the default continuation prompt tag), then applying the continuation re-installs only the work to be done by the handler up until the point that it returns; the dispatch machinery to invoke the button callback is not included in the continuation. A continuation captured during a button callback is therefore potentially useful outside of the same callback.
Che vorrebbe essere la traduzione di logging.
The GUI system logs the timing of when events are handled and how long they take to be handled. Each event that involves a callback into Racket code has two events logged, both of which use the gui-event struct:
(struct gui-event (start end name) #:prefab)
start field is the result of
(current-inexact-milliseconds) when the event handling starts. The end field is
#f for the log message when the event handling starts, and the result of
(current-inexact-milliseconds) when it finishes for the log message when an event finishes. The name field is the name of the function that handled the event; in the case of a
queue-callback-based event, it is the name of the thunk passed to
OK :grin: un altro post descrittivo, teorico, ma prossimamente, fose… :mrgreen: