Re: [boost] Asio formal review

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-13 15:37:14

Hi Thore,

--- Thore Karlsen <sid_at_[hidden]> 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