Lines Matching refs:to

12    A user interface thread must remain responsive to user requests, and
24    responsive to user requests even while the application has long
25    computations running. For example, the user might want to press a
26    "cancel" button to stop the long running computation. If the GUI
28    able to respond to user requests.
40    -  The GUI thread needs to offload work onto other threads without
41       waiting for the work to complete.
44    -  The GUI thread must be responsive to the event loop and not become
45       dedicated to doing the offloaded work.
64    The GUI thread offloads the work by firing off a task to do it using
66    When finished, the task posts an event to the GUI thread to indicate that the work is done.
67    The semantics of ``enqueue`` cause the task to eventually run on a worker thread
82    similar principles apply to any GUI using an event loop idiom. For
83    each event, the GUI thread calls a user-defined function ``WndProc`` to process an event.
93       // Queue for transmitting results from enqueued task to GUI thread.
106                          // User requested a long computation. Delegate it to another thread.
117                  // There is another result in ResultQueue for me to grab.
139       to a worker thread and immediately returns.
142    #. The GUI thread continues servicing the event loop. If it has to
148    into ResultQueue, and sends a message WM_POP_FOO to the GUI thread.
182    It is essential to use method ``task_arena::enqueue`` here.
188    The example uses a ``concurrent_queue`` for workers to communicate
189    results back to the GUI thread. Since only the most recent result
190    matters in the example, and alternative would be to use a shared