[boost] seeking commonality in futures/threader/demuxer/defer/etc models

From: simon meiklejohn (simon_at_[hidden])
Date: 2005-12-02 17:09:15

Q. Is it possible to isolate a core thread execution model
from the various libs currently on offer, and re-express
those libs in terms of the core model?

The core service amonst these libraries is
"Execution of abstracted tasks in an appropriate threads"
Task seems to be in common expressible as a function object

Major extension/variations include
- waitable return object (future/threader) vs. ad hoc reverse direction
   task execution (asio::demuxer/defer)
- threads resources shareable amongst different tasks
 (threader/demuxer/defer) vs thread created per action (futures,
  also possible with defer & threader styles)
- some guarantees given about which thread will do a given task
 (threader/demuxer/defer) vs guaranteed new thread (future)
- able to extend callbacks into windows message pump (defer)

I think the different return styles can be unified to some extent by
wrapper objects which operate like a void(void) function for exection,
but which package up a wrapped function with return values and expose
a wait() method on which the caller can wait for the result (essentially
what threader/futures do)

Futures autocreation of threads for each task is clearly implementable
on top of any of the others, though perhaps not as efficiently.

Guarantees about how a task will execute may not matter to all applications
but it critical to others. The asio::demuxer gives a guarantee that the
task will execute in a thread that has called demuxer::run, which may 
include
the thread which is doing the requesting - implication being that the call 
may
take place immediately. This is an excellent performance optimisation, but
the programmer may require stronger guarantees, perhaps against that very
optimisation.

Vague Conclusions.

I think its doable, I'd like to use such a boost library, i'd like it to be
flexible in terms of strategising the thread allocation, i'd like to be able
to use different models of thread allocator to solve different problems
from distruting load amongst threads to solving thread deadlock issues
to integrating my networking library with my GUI application.

I'd prefer it if someone smarter than myself could write the code, but if
they'd keep my requirements in mind while doing so (and treat my
defer submission as an extension to those requirements) then i'd be happy.

Cheers

Simon Meiklejohn