yield in Eventspaces
Yields control to event dispatching. See Eventspaces for details.
A handler procedure invoked by the system during a call to
yield can itself call yield, creating
an additional level of nested (but single-threaded) event handling.
See also
sleep/yield .
-
Dispatches an unspecified number of events, but only if the current thread is the current eventspace's handler thread (otherwise, there is no effect). The result is
#tif any events may have been handled,#fotherwise.
(yield-> valuev)
v:'waitor eventIf
vis'wait, andyieldis called in the handler thread of an eventspace, it starts processing events in that eventspace untilno top-level windows in the eventspace are visible;
no timers in the eventspace are running;
no callbacks are queued in the eventspace; and
no
menu-bar%has been created for the eventspace with'root(i.e., creating a'rootmenu bar prevents an eventspace from ever unblocking).
When called in a non-handler thread, returns immediately. In either case, the result is
#t.Evaluating
(is thus similar toyield'wait)(, except that it is sensitive to whether the current thread is a handler thread, instead of the value of theyield(current-eventspace))current-eventspaceparameter.If
vis an event in MzScheme's sense (not to be confused with a GUI event),yieldblocks onvin the same way as MzScheme'ssync, section 7.7 in PLT MzScheme: Language Manual, except that it may start asynconvmultiple times (but it will complete asynconvat most one time). If the current thread is the current eventspace's handler thread, events are dispatched until avsync succeeds on a MrEd event boundary. For other threads, callingyieldwith a MzScheme event is equivalent to callingsync. In either case, the result is the same that ofsync; however, if a wrapper procedure is associated withvviahandle-evt, it is not called in tail position with respect to theyield.Always use
(yieldinstead of a busy-wait loop.v)