|
Fibers
|
Posted: Dec 20, 2005 4:17 AM
|
|
The actual problem at hand is that threads just eat too many resources from the OS to be really useful for this kind of system.
NT Fibers - which are a kind of thread, but without the scheduling - might be a nice approach to this.
For handling socket communication, the server creates a Fiber for every accepted connection. In the main loop, it uses a select call to see which sockets are ready for processing, and actives the corresponding fibers by attaching them to a thread. Control is returned when the socket returns EWOULDBLOCK.
Multi-processor systems can use multiple worker threads, and fibers can be assigned to any available thread.
This basically combines the simple approach of creating threads for each connection, and the low resource usage of a reactor. Each handler can just, for example, keep on reading from a socket, and process the results as if it were the only running object. This avoids the overhead of having to save current progress/status before returning control, which a system built on select() would be forced to do, as you described in your article. This administration is now done by the fiber.
|
|