From: Thore Karlsen (sid_at_[hidden])
Date: 2005-12-13 10:53:45
On Tue, 13 Dec 2005 20:34:45 +1000, Matthew Vogt <mattvogt_at_[hidden]>
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.