----- Original Message ----- From: "Christopher Kohlhoff" <chris@kohlhoff.com> To: <boost@lists.boost.org> Sent: Tuesday, December 20, 2005 4:15 PM Subject: Re: [boost] Asio formal review
Hi Matt,
--- Matt Vogt <mattvogt@warpmail.net> wrote:
- 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.
I think this is sensible.
For now, I am just going to look at doing the above plus having an enum return value from run() indicating "interrupted", "out_of_work", "timed_out", etc. I think these changes have obvious utility, provided I can get the semantics correct and unsurprising.
[SNIP] I promised myself i'd shut up about these issues. Oh well... Wouldnt this problem be solved more naturally if an interface were exposed out of the demuxer for signalling the availability of more work as it arrives? The GUI thread could then be made to call back into demuxer::run only when appropriate rather than busily during idle time. I'm no expert on GUI frameworks, but if they expect to be called only in some designated thread then i'd be surprised if they didn't provide some channel for reflecting a minimal set of events into that thread. As previously discussed, the win32 message pump can easily be hijacked in this way. Cheers Simon