in we learned about threads and the queue mechanism that threads typically use to communicate with one another we also described the application of those ideas to guis in the abstract in we specialized some of these topics to the tkinter gui toolkit we're using in this book and expanded on the threaded gui model in generalincluding thread safety (or lack thereofand the roles of queues and locks now that we've become fully functional gui programmerswe can finally see what these ideas translate to in terms of code if you skipped the related material in or you should probably go back and take look firstwe won' be repeating the thread or queue background material in its entirety here the application to guishoweveris straightforward recall that long-running operations must generally be run in parallel threadsto avoid blocking the gui from updating itself or responding to new user requests long-running operations can include time-intensive function callsdownloads from serversblocking input/output callsand any task which might insert noticeable delay in our packing and unpacking examples earlier in this for instancewe noted that the calls to run the actual file processing should generally run in threads so that the main gui thread is not blocked until they finish in the general caseif gui waits for anything to finishit will be completely unresponsive during the wait--it can' be resizedit can' be minimizedand it won' even redraw itself if it is covered and uncovered by other windows to avoid being blocked this waythe gui must run long-running tasks in parallelusually with threads that can share program state that waythe main gui thread is freed up to update the display and respond to new user interactions while threads do other work as we've also seenthe tkinter update call can help in some contextsbut it only refreshes the display when it can be calledthreads fully parallelize long-running operations and offer more general solution howeverbecauseas we learned in only the main thread should generally update gui' displaythreads you start to handle long-running tasks should not update the display with results themselves ratherthey should place data on queue (or other mechanism)to be picked up and displayed by the main gui thread to make this workthe main thread typically runs timer-based loop that periodically checks the queue for new results to be displayed spawned threads produce and queue data but know nothing about the guithe main gui thread consumes and displays results but does not generate them because of its division of laborwe usually call this producer/consumer model--task threads produce data which the gui thread consumes the long-running task threads are also sometimes called workersbecause they handle the work of producing results behind the scenesfor the gui to present to user in some sensethe gui is also client to worker thread serversthough that terminology is usually reserved for more guisthreadsand queues