On 7 Jul 2014 at 8:35, Sebastian Schaetz wrote:
There is also Christophe Henry's Boost.Asynchronous. Just like the HPX guys he spent a lot of time thinking about this kind of problem and from what I understand, his solutions is reasonable. The interface is still a little rough around the edges but that can be changed. Advantage over HPX: it is a library already targeted at becoming part of Boost one day.
I agree with all of this assessment. I would add that I somewhat struggle to see how his "go it alone" approach fits snugly with what WG21 have already agreed is going to happen (his Preface in particular is stale) - I should worry his approach may become orphaned. Also, though he has taken time and care to have his approach fit somewhat with other Boost libraries present and future, I find the depth of that part somewhat lacking. None of this is insurmountable in a peer review of course. It looks to be a great library. Vicente, if you're reading you really should have a look at proposed Boost.Asynchronous. He's already done a lot of your todo list for Boost.Thread.
As for the original question, I think option one (dedicate a thread to each segment) is fine for now. Maybe it can be implemented with a pseudo task abstraction that can be exchanged with a real task abstraction (or whatever HPX or Boost.Asynchronous call it) once it is available. I would consider a fixed-size threadpool with not enough threads to run all segments a runtime-error (or compile-time if the threadpool allows for this) - for now.
My only qualm, really, is that proposed Boost.Asynchronous does not appear to me to implement pull-push pipeline management which is the hard part of a Pipelines implementation. I am under the possibly mistaken understanding that HPX does. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/