Re: [boost] [futures] reference-counted futures

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-28 08:48:52

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 28 May 2008 05:55 am, Johan Torp wrote:
> Do you propose to remove reference counting from futures and use
> shared_ptr<future<..>> instead?

No, the mentions I made of shared_ptr were not important.  I was only trying 
to convey that promise::has_future could be easily implemented by imagining a 
typical implementation of promise/future where they both are implemented by 
having a shared_ptr to some common object.

> I believe the main motivation for a unique_future was to be able to move
> large/expensive types in the get-function instead of copying them.
>
> shared_future<R> requires it's client to copy the data to move it into
> their own data structures. It has the following signature:
> R const & get() const;
>
> unique_future<R> moves the value out of the future and is "consumed" once
> get() has been called. It has the following signature:
> R&& get();
>
> I don't like having both shared_future and unique_future either. One could
> perhaps distinguish between move-get and const_ref-get somehow and only
> allow the former if use_count == 1. One problem is that the promise
> typically belongs to some other thread and new futures can be created
> concurrently after having queried use_count. Another option is declaring
> whether the future is unique or shared as a parameter in the futures
> constuctor. An exception could be thrown if you try to create more futures
> from a uniquely "owned" promise.
>
> Not distuinguishing between unique and shared might remove some type safety
> and clarity in user code. Some of the N2627 future proposal authors can
> probably provide more insight.

This seems unrelated to what I was trying to get at with promise::has_future.  
The idea is a promise-fulfilling thread can query promise::has_future if it 
likes, and choose to exit early if there are no futures out there that might 
be interested in its result value.  Or, if the promise-fulfilling thread is 
intended to cause some side-effects independent of setting futures, it can 
proceed and ignore promise::has_future.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIPVTC5vihyNWuA4URAnD6AJ9aIPeYkU59JV5i/XOAlN65rV3w2wCfbJs9
XjYN/k3k3HaOXslKjl24XCw=
=YQS7
-----END PGP SIGNATURE-----