On Mon, Sep 13, 2004 at 10:18:00AM -0500, Aaron W. LaFramboise wrote:
But while that might be possible on GNU/Linux, it might be impossible on windows (for example). The demand to provide a portable interface forces us to create (hidden) threads therefore. If a user decided that he only needs one thread and the library is not allowed to implement the requested interface by running two or more threads internally, then how can I implement an interface that allows one to wait for events on 100 sockets, a timer, a few named pipes, a fifo and some large diskfile I/O at the same time? That is possible on linux, but I failed to figure out how this can be done on windows :/
I am confused. What feature is missing on Windows? It is my perception that the Windows API is quite as expressive as anything Linux has.
No, I am confused. You do as if it trivial. But where is the answer to my question? How can I implement an interface that allows one to wait for events on 100 sockets, a timer, a few named pipes, a fifo and some large diskfile I/O at the same time? Is your answer WaitForMultipleObjects ? Then 1) what about the limit of 64? And 2) How can I use that to wait for events on SOCKET's? The only thing I can find for that is WSAWaitForMultipleEvents. But obviously you can call WSAWaitForMultipleEvents *and* WaitForMultipleObjects at the same time (without using threads). -- Carlo Wood <carlo@alinoe.com>