Re: [boost] Asio formal review

From: simon meiklejohn (simon_at_[hidden])
Date: 2005-12-20 01:24:10

----- Original Message ----- 
From: "Christopher Kohlhoff" <chris_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, December 20, 2005 4:15 PM
Subject: Re: [boost] Asio formal review

> Hi Matt,
> 
> --- Matt Vogt <mattvogt_at_[hidden]> 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