Hi Thore, --- Thore Karlsen <sid@6581.com> wrote:
I was wondering the same thing. For Windows clients I like WSAAsyncSelect() and just driving the sockets through the GUI message loop, since I don't have to worry about threading issues. Another reason I like it is because I can have several dozen windows open, each one a separate component. I really can't afford to have several threads (at least one to drive the demuxing and one for the async resolves) created for each window, and I would prefer not to require each window to have to register with a shared demuxing thread.
Any ideas?
I have pondered this from time to time, but haven't been able to decide on the ideal interface. Here are some of the candidates: - demuxer::run() overload that takes a timeout (possibly two overloads, one taking an absolute time and the other taking a duration) which means it will run for that long regardless of how much work it performs. - demuxer::perform_work() function that runs until it has performed exactly one item of work. - demuxer::perfork_work() function that takes a timeout and runs until the time has elapsed or it performs one item of work. The problems I ran into when thinking about this include: - How to tell that the demuxer has finished all its work? Boolean return value from the above functions? Is it better for true to mean its done or that it has more to do? - What happens with multiple thread calling these functions? What is the correct interaction between these functions and demuxer::interrupt() and demuxer::reset()? Do we need an additional return value from run()/perform_work() that means the demuxer was interrupted? I see all these options as additions to the current interface, so I chose to leave it as a task for future thought. I'd welcome any input on it you might have. Cheers, Chris