I was a contractor, so I worked on several systems for various customers (banks, mostly). There were a few approaches - one was multi-threading, the other was

I was a contractor, so I worked on several systems for various customers (banks, mostly). There were a few approaches - one was multi-threading, the other was to divide your task up into small enough pieces to not violate the 1/10th sec. rule, and the other was to install another product that gave you Message Queueing. When splitting up your unit of work, you would define your own custom events such that when the event loop came around to processing your events, the granularity was small enough to keep the system responsive. BTW, events were prioritized by the OS, so not all events were treated equally. Same with NT. So you'd think of your application as a state machine, with the transitions being driven by the OS events appearing. Message Queueing (the current darling of the scalability crowd) has been around a lot longer than people realize. :) Also understand that for line-of-business applications, once the screen was done painting and you were waiting for user action, the event loop went into "idle" state. So in most cases you only had to worry about timeouts when you were communicating with a server (database or mainframe).