The use of polling and coroutines to handle asynchronous events places too much responsibility on the application programmer who must obtain and release control of the processor. Polling systems are simple but they prevent true multitasking, restrict the interface to a single focus of control and force the user interface to keep the notion of an active window to maintain context. Further, since a polling loop will test the supported devices in a specific order, some inputs have a slightly higher priority than the others.
In a system based on polling, programmers can inadvertently lockup the system while debugging the user interface. Such a lockup typically leaves them asking the question so frequently asked by Smalltalk users, "When I am in this part of the window what code gets executed when I do this (e.g., move the Mouse)?". These problems arise because **Smalltalk’s controllers** (discussed below) **poll for both input and control**. When input is sensed by one controller, it asks the other controllers if they want control, the first controller that wants control processes the input. This confusion is indicative of the problems surrounding polling mechanisms.
DOT FROM lambda-browsing
It is often difficult to implement a clean solution to a problem in a polling-based system. For example, the decision to use a single event loop in systems like the Macintosh makes writing complex applications very difficult and multitasking is hard to introduce (e.g., MultiFinder). As a result, the event loops arc complicated and monolithic.