On Tue, 13 Dec 2005 20:34:45 +1000, Matthew Vogt <mattvogt@warpmail.net> wrote:
I wonder how the demuxer would be incoporated into a GUI event-loop-based program, particularly in toolkits which mandate that GUI updates can occur from a single thread only? Perhaps the 'run' member function could be called in a non-blocking fashion? Or perhaps the demuxer could queue ready handler callbacks for later execution, rather than invoking them directly? Then the GUI thread could execute all pending handler functions on idle.
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? -- Be seeing you.