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.
Best,
Vicente