You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The io_service class is currently a thin wrapper around Win32 IO completion-port and requires clients to manually manage their own threads to call process_events().
This can be fairly easily used to build a fixed-size thread-pool by spawning N threads and having each thread call io_service::process_events().
However, there are advantages to using the built-in Win32 thread-pool facilities to implement the thread-pool instead of manually spawning/managing your own pool of threads.
One benefit is that the OS is able to dynamically spin up more threads or shutdown idle threads as required.
Another benefit is that multiple libraries/frameworks can share the same underlying pool of threads without needing to go through the same API.
Otherwise, if your application uses, say 3 libraries, each of which create their own thread-pools, then you could end up with 3N threads being created across 3 separate thread-pools. If all of those libraries instead used the OS thread pool then a single pool of threads can be used to multiplex execution of tasks from each of those libraries.
The text was updated successfully, but these errors were encountered:
Commit 91e9b03 adds basic io_service that wraps IOCP.
Commit 8cf10ce adds some async file I/O.
Still need to add some documentation to README for this.
The
io_service
class is currently a thin wrapper around Win32 IO completion-port and requires clients to manually manage their own threads to callprocess_events()
.This can be fairly easily used to build a fixed-size thread-pool by spawning N threads and having each thread call
io_service::process_events()
.However, there are advantages to using the built-in Win32 thread-pool facilities to implement the thread-pool instead of manually spawning/managing your own pool of threads.
One benefit is that the OS is able to dynamically spin up more threads or shutdown idle threads as required.
Another benefit is that multiple libraries/frameworks can share the same underlying pool of threads without needing to go through the same API.
Otherwise, if your application uses, say 3 libraries, each of which create their own thread-pools, then you could end up with 3N threads being created across 3 separate thread-pools. If all of those libraries instead used the OS thread pool then a single pool of threads can be used to multiplex execution of tasks from each of those libraries.
The text was updated successfully, but these errors were encountered: