The model you are describing (incoming requests wait on a queue until a thread is ready to work on them) is a very simple form of async processing. Essentially,

The model you are describing (incoming requests wait on a queue until a thread is ready to work on them) is a very simple form of async processing. Essentially, you are saving your context in some (relatively) small objects on the heap and waiting for the right time for that context to get picked up and processed. It's only a slight logical extension to allow you to suspend and resume multiple times in handling a single request. As far as using a fixed pool goes: others have replied similarly but by doing that you are completely letting your CPU cores go to waste whenever you are waiting for any underlying IO. For many classes of applications, they will end up topping out at only a few percent CPU usage.