Thanks for that brief lesson, Ed.

You describe a variation of what I was used to (and reasonably intimate with) on the mainframe IBM OSes. There a 'wait' had nothing "cooperative" about it - the operating system got control and preempted that task and dispatched another. In other words it was totally controlled by the OS and there was (virtually) nothing that a task could do to prevent this.
Win seems to permit its 'tasks' to decide for themselves. Nothing wrong with that except, possibly, that one must be somewhat more intimate with each such 'task'.

So I can now conclude that Dragan was indeed correct. Another piece of a huge puzzle is now in place.

Thanks,

Jim N

>>I, too, was going to respond to Barbara similarly to yours, but then it occurred to me that the OS (Win in our case) has to be designed to handle such "wait states" appropriately. Personally, I have never heard of anything except timeslicing in relation to Win. This *could* mean that Win would simply continue to wait out the slice even in the (non)event of a wait state in the currently dispatched program. Do you happen to know more details (or even have some observations that suggest more smarts than this in Win)???
>>
>
>While Win32 uses a 'timeslice' concept, a thread has the ability to release control back to the operating system pending an event - hardware or software; there's nothing preventing cooperative multitasking, and in fact, there are several APIs that allow a thread, fiber or process to release their allotted time until one or more event occurances are signalled (you might want to look at the assortment of WaitFor Win32 API calls to see the variety of ways that a thread can avoid needlessly burning cycles while waiting for something to happen.)
>
>A timesliced strategy to preemptive multitasking doesn't prevent the operating system from allowing or even encouraging cooperative multiprocessing. You might want to read Jeff Richter's Advanced Windows, chapters 2, 3 and 9 deal with process and thread strategies and thread synchronization, the first few pages of Chapter 10 on Windows messages have a very concise and descriptive summary of how multitasking and asynchronous events are handled (the majority of Chapter 10 deals with Windows Object messaging in general.
>
>>Cheers
>>
>>Jim N
>>
>>>>
>>>>Any CPU can handle only one task at a time and must use time slicing to handle multiple tasks. IOW, it's not a VFP limitation, it's a CPU limitation. I have no first-hand experience with multiple processors, but have heard horror stories from those who have.
>>>
>>>Not necessarily. You may have a thread which does some disk/floppy/other HW operation, and these may use little processor time, so if it happens in a separate thread, the original thread may keep singing almost undisturbed. It doesn't have to wait for the HW issues to get done, so there's still some gain.