Boost logo

Boost :

Subject: Re: [boost] Futures - Reviews Needed (January 5, 2009)
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-01-19 02:48:22

----- Original Message -----
From: "Johan Torp" <johan.torp_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, January 19, 2009 6:59 AM
Subject: Re: [boost] Futures - Reviews Needed (January 5, 2009)

> However, thread pools do not aim to provide good latency which might make a
> such future implementation useless for scheduling related usage (which might
> still be ok since it could be the best design option we have). I'd love to
> hear the authors views on this.

Could you develop the use case you have in mind.

> Actually, I started writing a reply but I couldn't really understand your
> implementation. I was hoping one of the authors would reply first and I
> could join in later. To solve the complexity problem, I agree we need to
> expose some stateful abstraction and can't do with just free functions.
Replay to the post. Let me know what you don't understad.
> If we choose require a third thread (or thread pool) for future composition,
> I'm sure there are lots of nice interfaces like your proposal above. I don't
> want to spend too much time designing these fancier features now though.

Which other features would you want?

> Vicente Botet Escriba wrote:
>>> #1 Come up with a better wait_for_any mechanism (probably some kind of
>>> future container, another idea is exposing the internal condition
>>> variable)
>> Are you requiring some kind of public registration on completion as used
>> by the future_waiters?
>> Anthony has sais that it could be something like that, but no concrete
>> porposal for the the moment.
> At this point I'm not suggesting anything. I'd like the authors
> acknowledgement that this is a problem first. Who knows, maybe they have
> some insight which makes it a non-problem. I'd rather build consensus on
> what the problems are first, then solve the problems.
I understand
> I would not be surprised if requiring a third thread for future composition
> would render it useless for many of Gaskill's use cases, libpoet and asio -
> which means most of the identified use cases. But I'm far from sure.

Could you or someone develop these needs.


Boost list run by bdawes at, gregod at, cpdaniel at, john at