Editing OS/2 (section)

===Problems===
Some problems were classic subjects of comparison with other operating systems:

*''Synchronous input queue (SIQ)'': if a GUI application was not servicing its ''window messages'', the entire GUI system could get stuck and a reboot was required. This problem was considerably reduced with later Warp 3 fixpacks and refined by Warp 4, by taking control over the application after it had not responded for several seconds.<ref>see IBM Developer Connection for OS/2, Internal Fixpack 12J</ref><ref name="pcw199407_handson">{{ cite magazine | title=Just jamming | magazine=Personal Computer World | date=July 1994 | last1=Bidmead | first1=Chris | pages=565–568 }}</ref>{{rp|pages=565|quote=A recurring problem you might have with OS/2 - I know I do - is lockup due to the input queue getting jammed. The symptom is a system that just stops responding to input from the keyboard and/or mouse. It's a weakness in the OS/2 design that Microsoft has crowed about in the past, although my sources tell me that it was Microsoft who put it there in the first place.}}
*''No unified object handles (OS/2 v2.11 and earlier)'': The availability of threads probably led system designers to overlook mechanisms which allow a single thread to wait for different types of asynchronous events at the same time, for example the keyboard and the mouse in a "console" program. Even though ''select'' was added later, it only worked on network sockets. In case of a console program, dedicating a separate thread for waiting on each source of events made it difficult to properly release all the input devices before starting other programs in the same "session". As a result, console programs usually polled the keyboard and the mouse alternately, which resulted in wasted CPU and a characteristic "jerky" reactivity to user input. In OS/2 3.0 IBM introduced a new call for this specific problem.<ref>KbdGetConsole() and DosWaitMuxWaitSem(), see ''Control Program Programming Guide and Reference'', IBM OS/2 Toolkit</ref>