Can you than please give a technical reason for you to insist on waiting on more than 64 threads in a single API call, having simply too many threads for good performance anyway when IO Completion Ports could be used instead?
He probably doesn't have 64 threads, but he may have much more than 64 files or sockets. After all, the response was to the statement that "WaitForMultipleObjects as a kind of super-select to wait on anything". It clearly isn't, with this arbitrary limitation.
The problem with Windows is that there isn't any such super-select, unlike on Linux (see epoll, signalfd, timerfd...). You should take a look at my SO answer which lists six different ways to use sockets in Windows: http://stackoverflow.com/questions/11830839/when-using-iocp-...
Whatever he has more, waitfor is not the optimal way on Windows for that so it's still a complaint that round holes on Win32 are poor fit for his cubes. First choosing tools then complaining that they don't fit to some goal is typical for beginners.
Can you than please give a technical reason for you to insist on waiting on more than 64 threads in a single API call, having simply too many threads for good performance anyway when IO Completion Ports could be used instead?
He probably doesn't have 64 threads, but he may have much more than 64 files or sockets. After all, the response was to the statement that "WaitForMultipleObjects as a kind of super-select to wait on anything". It clearly isn't, with this arbitrary limitation.
The problem with Windows is that there isn't any such super-select, unlike on Linux (see epoll, signalfd, timerfd...). You should take a look at my SO answer which lists six different ways to use sockets in Windows: http://stackoverflow.com/questions/11830839/when-using-iocp-...
Whatever he has more, waitfor is not the optimal way on Windows for that so it's still a complaint that round holes on Win32 are poor fit for his cubes. First choosing tools then complaining that they don't fit to some goal is typical for beginners.
8 replies →