[futures] composite or

[Hartmut Kaiser]

 
Frank Mori Hess wrote:

> > > Future<bool> operator||(const Future<T> &a, const Future<U> &b);
> >
> > 1. Why do you would do that? Do you have a use case?
>
> Making active functions that take futures as arguments and
> return futures as return values is the primary feature of
> libpoet.  See
>
> http://www.comedi.org/projects/libpoet/
>
> So the operator|| above would be used if you wanted to || two
> results and pass the result of the || to another active
> function without blocking waiting for the futures to become
> ready.  Really it was just an example though, I'm not
> currently planning to implement this (although maybe I will
> someday if I discover it to be useful).

Passing the result of f1 || f2 does not block execution at all. F1 || f2
yields just another future you will have to dereference first to make it
returning it's value (or blocking, if the value is not available).

So I'ld rather cross the bridge, when I'm there. Relying on fictional use
cases is at least questionable.

> > 2. If you really have to do that, simply do not include the
> header(s)
> > defining the operators.
>
> I don't really have to define an operator||, I could just
> give the function an ordinary name.  My point is, composing
> futures like in Thorsten Schütt's implementation doesn't
> really have to define an operator|| either.  And, if I had to
> choose which function had a more legitimate claim to use
> operator||, I'd choose my example.
>
> Not including the headers isn't really a solution, since it
> precludes the use of the conflicting functions in the same code.

This doesn't preclude anything. You said you don't _want_ to use the
overloaded semantics of futures at all (because you don't like them). How
this may then conflict with other code? I hold my point: just don't include
the header containing the questionable operators and you don't have to pay
for them.

> Pointless overloading isn't a good thing.   What does it buy
> you here?  A
> pair of parenthesis.

Syntactic sugar improves expressiveness, which makes code more readable. But
as always this is a matter of style and personal preference. I don't want to
start a religious discussion here. Just don't use the syntactic sugar, if
you don't like it.

The usage of operator overloading has one advantage over a similar solution
using functions, though. When combining futures you ultimately want to
flatten the composed return types: i.e. for a f1 || f2 || f3 (with different
return types T1, T2 and T3) you want to get a variant<T1, T2, T3> as the
composite return type and not a variant<variant<T1, T2>, T3> (as you would
get using simple functions taking two parameters).

This naturally involves some meta template magic to construct the required
return types. Using functions you'll have to do this by hand, using
operators you can reuse existing meta-template frameworks like proto
allowing to implement this with minimal effort.

Regards Hartmut



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

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

On Wednesday 14 March 2007 15:26 pm, Braddock Gaskill wrote:
> I would also prefer fail() to
> set_exception()...it seems more descriptive since it is more than just
> an accessor method.

Oh, and clearly the true name of promise::set_exception() is
promise::break().

- --
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFF+F2v5vihyNWuA4URAnLiAKCw93g+YEd8kxYEI5qH2jKr+ahazwCglYkT
mqfpX1p5kStN9NlI4LcKuR8=
=w2GX
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

 
Braddock Gaskill wrote:

> > Instead of going with generalized future composition, I've
> tried the
> > route of
> > 'wait_all(<future-list>) ' and 'wait_any(<future-tuple>)'
>
> This is exactly what I personally would like to see.  I don't
> relish the thought of digging out a return type or exception
> from a future<variant<float, string, tuple<int, double, bool>
> > >.  I would just want something that wakes me up when
> dinner is ready and let me figure out which of my futures are
> valid or have failed, if I even care.

You don't need to use the return type, if you don't want to use it
afterwards. And in the case you're interested in the actula return value, a
function like above will have to return the variant<float, string,
tuple<int, double, bool> > as well. So what do you gain from using a
function? Operator overloading gives you variable future counts with far
less coding effort. With functions you have to spell out a specialization
for every possible number of futures you want to combine.

> wait(f1 || (f2 && f3));
> might be nice syntax, does actually add functionality, and is
> simple enough as well.

Yeah, sure. The library in the vault has a futurize() function doing exactly
what you want, just pass a arbitrary complex future expression to it. No
need to know the returned data type.

Regards Hartmut

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov]

Braddock Gaskill wrote:

> So, that would mean that for f3 = f1 || f2, if f1 propagates an
> exception while f2 succeeds, f3 still propagates an exception?

I think that one sensible meaning of f1 || f2 is to wait until either one of
f1 or f2 returns a value, or both fail.

The "first to complete" approach is supported by my proposed future<>, but
not in a composable way. You can hand the same future<> to two producers and
the first one to place a value or an exception into it wins. But I haven't
investigated the infrastructure that would allow operator||.

As for operator&&, it doesn't deliver any extra functionality. Instead of
wating for f1 && f2, you just wait for f1, then f2:

future<int> f1 = fork( f, x );
future<int> f2 = fork( f, y );

std::cout << f1 + f2 << std::endl;

There's no need to do:

future< pair<int, int> > f3 = f1 && f2;
pair<int,int> p = f3;
std::cout << p.first + p.second << std::endl;

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

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

On Wednesday 14 March 2007 16:38 pm, Hartmut Kaiser wrote:

> Frank Mori Hess wrote:
> > results and pass the result of the || to another active
> > function without blocking waiting for the futures to become
> > ready.  Really it was just an example though, I'm not
> > currently planning to implement this (although maybe I will
> > someday if I discover it to be useful).
>
> Passing the result of f1 || f2 does not block execution at all. F1 || f2
> yields just another future you will have to dereference first to make it
> returning it's value (or blocking, if the value is not available).

I thought you asked me why I'd want to use the operator|| that I suggested,
so I gave an example of its use.  You seem to be talking about the other
operator|| that I didn't like.

> > Not including the headers isn't really a solution, since it
> > precludes the use of the conflicting functions in the same code.
>
> This doesn't preclude anything. You said you don't _want_ to use the
> overloaded semantics of futures at all (because you don't like them).
> How this may then conflict with other code? I hold my point: just don't
> include the header containing the questionable operators and you don't
> have to pay for them.

Ah, I was thinking the operator||, etc was the only way provided to compose
the futures.  If they are also available via normal function names, then I
retract my complaint.

> The usage of operator overloading has one advantage over a similar
> solution using functions, though. When combining futures you ultimately
> want to flatten the composed return types: i.e. for a f1 || f2 || f3
> (with different return types T1, T2 and T3) you want to get a
> variant<T1, T2, T3> as the composite return type and not a
> variant<variant<T1, T2>, T3> (as you would get using simple functions
> taking two parameters).
>
> This naturally involves some meta template magic to construct the
> required return types. Using functions you'll have to do this by hand,
> using operators you can reuse existing meta-template frameworks like
> proto allowing to implement this with minimal effort.

Why couldn't you just overload the function to take varying numbers of
arguments?  I'll just use the name "compose_variant" for illustration:

variant<T1, T2> compose_variant(T1 t1, T2 t2);
variant<T1, T2, T3> compose_variant(T1 t1, T2 t2, T3 t3);
// ...

- --
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFF+GBe5vihyNWuA4URAgpyAJ9yDcnWgZtV8nkke4uKDsMUZDx/CACdEswq
rDoy7kzchQgP1CxfEP4OG/4=
=ElUK
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Gpderetta]

On 3/14/07, Peter Dimov <pdimov@...> wrote:

> Braddock Gaskill wrote:
>
> > So, that would mean that for f3 = f1 || f2, if f1 propagates an
> > exception while f2 succeeds, f3 still propagates an exception?
>
> I think that one sensible meaning of f1 || f2 is to wait until either one of
> f1 or f2 returns a value, or both fail.
>
> The "first to complete" approach is supported by my proposed future<>, but
> not in a composable way. You can hand the same future<> to two producers and
> the first one to place a value or an exception into it wins. But I haven't
> investigated the infrastructure that would allow operator||.
>
> As for operator&&, it doesn't deliver any extra functionality. Instead of
> wating for f1 && f2, you just wait for f1, then f2:
>
> future<int> f1 = fork( f, x );
> future<int> f2 = fork( f, y );
>
> std::cout << f1 + f2 << std::endl;
>
> There's no need to do:
>
> future< pair<int, int> > f3 = f1 && f2;
> pair<int,int> p = f3;
> std::cout << p.first + p.second << std::endl;
>

While there is no added functionality to being able to wait to two or
more futures at the same time, it could improve performance: the
waiting thread need to be awaken only once and you could save some
context switches.

gpd
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christopher Kohlhoff]

On Wed, 14 Mar 2007 15:50:34 -0400, "Howard Hinnant"
<hinnant@...> said:
> And am somewhat disappointed that the low-level worker function needs  
> to be aware of promise.

In some cases you do want it to be aware of the promise if you chain
many async operations together, and only fulfill promise at the end of
the chain. However a simpler interface for the one-async-operation case
would be nice, I agree.

> What if there existed a:
>
> template <class R>
> template <class F>
> promise_functor<R, F>
> promise<R>::operator()(F f);
>
> This would be in addition to the current setter functionality in  
> promise.

Hmm, I think I'd prefer a non-member function to make the distinction
between that act of settingthe promise and the act of composing another
function object clearer when reading the code. I don't see any
implementation reason to make it a member function - is there one?

Cheers,
Chris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Hartmut Kaiser]

 
Frank Mori Hess wrote:

> > The usage of operator overloading has one advantage over a similar
> > solution using functions, though. When combining futures
> you ultimately
> > want to flatten the composed return types: i.e. for a f1 || f2 || f3
> > (with different return types T1, T2 and T3) you want to get a
> > variant<T1, T2, T3> as the composite return type and not a
> > variant<variant<T1, T2>, T3> (as you would get using simple
> functions
> > taking two parameters).
> >
> > This naturally involves some meta template magic to construct the
> > required return types. Using functions you'll have to do
> this by hand,
> > using operators you can reuse existing meta-template frameworks like
> > proto allowing to implement this with minimal effort.
>
> Why couldn't you just overload the function to take varying
> numbers of
> arguments?  I'll just use the name "compose_variant" for illustration:
>
> variant<T1, T2> compose_variant(T1 t1, T2 t2);
> variant<T1, T2, T3> compose_variant(T1 t1, T2 t2, T3 t3);
> // ...

Ease of implementation. No need to implement a varying number of overloads
for one function or a single complex function having all but one default
arguments. But that's a matter of style and taste...

Regards Hartmut


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christopher Kohlhoff]

On Wed, 14 Mar 2007 15:26:11 -0400, "Braddock Gaskill"
<braddock@...> said:

> On Wed, 14 Mar 2007 14:09:37 -0400, Frank Mori Hess wrote:
> > Another suggestion is to rename promise::set() (boring) to
> > promise::fulfill() (makes me smile).  And if there is an opportunity to
> > work the name "empty_promise" in as a class or a concept, that would be
> > clever too.
>
> Personally, I love your fulfill() name.  I would also prefer fail() to
> set_exception()...it seems more descriptive since it is more than just an
> accessor method.  I didn't want to stray TOO far from Peter's C++
> language proposal though.

I totally agree on using fulfill/fail rather than set/set_exception.
IMHO pithy names like that also aid in understanding the concepts.
Perhaps Peter can be persuaded :)

I also didn't see an operator() on the promise<T> to set the value
(although I might have missed it). I think that's important because it
lets a promises participate more readily in boost::bind compositions,
etc.

Cheers,
Chris
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Howard Hinnant]

On Mar 14, 2007, at 5:33 PM, Christopher Kohlhoff wrote:

>
>> What if there existed a:
>>
>> template <class R>
>> template <class F>
>> promise_functor<R, F>
>> promise<R>::operator()(F f);
>>
>> This would be in addition to the current setter functionality in
>> promise.
>
> Hmm, I think I'd prefer a non-member function to make the distinction
> between that act of settingthe promise and the act of composing  
> another
> function object clearer when reading the code. I don't see any
> implementation reason to make it a member function - is there one?

No I don't think there's a reason.  A friend free function can do  
anything a member can.  I think we're just looking at syntax:

future<std::string> resolve(std::string host_name)
{
     promise<std::string> result;
     boost::asio::ip::tcp::resolver::query query(host_name, "0");
     resolver_.async_resolve(query,  
result(boost::bind(&Resolver::handle_resolve, this, _1, _2)));
     return result;
}

vs:

future<std::string> resolve(std::string host_name)
{
     promise<std::string> result;
     boost::asio::ip::tcp::resolver::query query(host_name, "0");
     resolver_.async_resolve(query, make_promise_functor(result,  
boost::bind(&Resolver::handle_resolve, this, _1, _2)));
     return result;
}

-Howard

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov]

Howard Hinnant wrote:

>>> What if there existed a:
>>>
>>> template <class R>
>>> template <class F>
>>> promise_functor<R, F>
>>> promise<R>::operator()(F f);

I'd actually expect from this syntax to call f and install the result into
the promise in one easy step. :-)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Howard Hinnant]

On Mar 14, 2007, at 8:01 PM, Peter Dimov wrote:

> Howard Hinnant wrote:
>
>>
>>>
>>>> What if there existed a:
>>
>>>
>>>>
>>
>>>
>>>> template <class R>
>>
>>>
>>>> template <class F>
>>
>>>
>>>> promise_functor<R, F>
>>
>>>
>>>> promise<R>::operator()(F f);
>
> I'd actually expect from this syntax to call f and install the  
> result into
> the promise in one easy step. :-)

That sounds like a thread launch, which indeed ought to be easy.

We've got (at least) 4 basic concepts floating around here:

* return_value<R>

This is a private implementation detail class that nobody ever sees.  
It is not copyable nor movable.  It represents the result of a  
computation, which can be either normal or exceptional.  It has  
getters and setters for normal and exceptional results.  It lives on  
the heap and various handles share its ownership.

* future<R>  // return_value getter

This forwards a getter request to return_value<R>.  The getter may  
need to wait for a signal from a setter.

* promise<R>  // return_value setter

This is a setter of return_value<R>, signaling any waiting getters.  
Setting normal or exceptional result is explicit.

* functor<R, F>  // return_value setter

This is a functor that executes a function F and stores the normal or  
exceptional result in a return_value<R>, possibly via a promise<R>.  
The result setting is implicit, depending on whether F returns  
normally, or has an exception propagate out of it.

Purposefully (and wisely imho) left out of this mix is what actually  
executes a setter for return_value<R>.  functor<R, F> and promise<R>  
are simply thin interfaces to setting return_value<R>.  But they don't  
represent asynchronous execution.  Thus you can create a function that  
calls promise<R>::set(r) which is asynchronously executed, say in a  
thread or a thread_pool.  Or you can adapt an existing function by  
constructing a functor<R, F> with it, and then execute that adapted  
function in a thread or thread_pool.  Either way, the setting of  
return_value can happen synchronously, in a dedicated thread  
asynchronously, or be queued in a container of functors (possibly  
priority sorted) waiting to be processed.

Ultimately I think we want to support syntax along the lines of:

     future<T> t = f( b );
     c = g( d );
     e = h(t(), c);

whereby functors and promises are hidden in relatively low level code,  
and high level code can just get a future, assume that it is being  
executed asap, and then join with it later.  Perhaps that morphs the  
above example into:

std::thread_pool launch_in_pool;

int main()
{
     std::future<T> t = launch_in_pool(std::bind(f, b));
     c = g( d );
     e = h(t(), c);
}

-Howard

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Kowalke Oliver (QD IT PA SI)]

Hello,

> I've made a futures implementation in the hopes of combining
> the best features from all the proposals and various
> implementations currently floating around.  It is still rough
> around the edges, but is mostly covered by unit tests.
>
> http://braddock.com/~braddock/future/
>
> I'm looking for input.  I'd be willing to add additional
> functionality needed and progress it to the point where it
> could be formally submitted into boost if there is interest.  
> It could perhaps be merged into the existing futures
> implementation in the vault to add combined groups, etc.
>
> I used Peter's exception_ptr code, which he said he would
> post under a boost license.
>
>   -Braddock Gaskill

I've tested your implementation with a thread and I get sometimes an
segmentation fault (linux, gcc-4.1.0).
File future_detail.hpp line 79 causes the segmentation fault.
Regards, Oliver

Code:

#include <cstdlib>
#include <iostream>
#include <stdexcept>
#include <string>

#include <boost/bind.hpp>
#include <boost/function.hpp>
#include <boost/thread.hpp>

#include "future.hpp"

struct X
{
        std::string execute()
        { return "std::string X::execute()"; }
};

void execute(
        boost::promise< std::string > p,
        boost::function< std::string() > fn)
{ p.set( fn() ); }

int main( int argc, char *argv[])
{
        try
        {
                X x;
                boost::function< std::string() > fn(
                        boost::bind(
                                & X::execute,
                                x) );
                boost::promise< std::string > p;
                boost::future< std::string > f( p);
                boost::thread t(
                        boost::bind(
                                & execute,
                                p,
                                fn) );

                std::cout << f.get() << std::endl;

                t.join();

                return EXIT_SUCCESS;
        }
        catch ( std::exception const& e)
        { std::cerr << e.what() << std::endl; }
        catch ( ... )
        { std::cerr << "unhandled exception" << std::endl; }

        return EXIT_FAILURE;
}

Gdb:

Program terminated with signal 11, Segmentation fault.
#0  basic_string (this=0xbff79740, __str=@0x0) at
/opt/gcc-4.1.2-src/src/i486-linux-gnu/libstdc++-v3/include/bits/basic_st
ring.h:283
283
/opt/gcc-4.1.2-src/src/i486-linux-gnu/libstdc++-v3/include/bits/basic_st
ring.h: Datei oder Verzeichnis nicht gefunden.
        in
/opt/gcc-4.1.2-src/src/i486-linux-gnu/libstdc++-v3/include/bits/basic_st
ring.h
(gdb) bt
#0  basic_string (this=0xbff79740, __str=@0x0) at
/opt/gcc-4.1.2-src/src/i486-linux-gnu/libstdc++-v3/include/bits/basic_st
ring.h:283
#1  0x0804d8da in boost::detail::future_impl::get<std::string>
(this=0x8055048, value=0x0) at
/home/kowalke/Projects/test_future/src/future_detail.hpp:79
#2  0x0804d94b in boost::future<std::string>::get (this=0xbff796c4) at
/home/kowalke/Projects/test_future/src/future.hpp:210
#3  0x0804a007 in main () at
/home/kowalke/Projects/test_future/src/test.cpp:43
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

On Thu, Mar 15, 2007 at 08:24:43AM +0100, Oliver.Kowalke@... wrote:
> > I've made a futures implementation in the hopes of combining
> > [...]  It is still rough around the edges, but is mostly
>
> I've tested your implementation with a thread and I get sometimes an
> segmentation fault (linux, gcc-4.1.0).

Thanks Oliver, I'll get that fixed this afternoon.

Since there definitely does seem to be interest in this, I'll also go
back and clean up some of those "rough edges", get a real
multi-threaded unit test in place, and get in a few of the new batch
of good ideas so people can really start playing with this.

        -braddock

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Peter Dimov]

Peter Dimov wrote:

> I will update the files to use the Boost license in a few days (and will
> link to the papers from the front page as soon as the mailing is made
> officially available on the committee web site).

FYI, I did that. Two more papers that may be of interest:

N2178, Proposed Text for Chapter 30, Thread Support Library [threads]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2178.html

N2195, Proposed Text for Chapter 29, Atomic Operations Library [atomics]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2195.html

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

> On Thu, Mar 15, 2007 at 08:24:43AM +0100, Oliver.Kowalke@... wrote:
>> I've tested your implementation with a thread and I get sometimes an
>> segmentation fault (linux, gcc-4.1.0).
>
> Thanks Oliver, I'll get that fixed this afternoon.

There is a new version of my future implementation at:
http://braddock.com/~braddock/future/

CHANGES:
-fixed this seg-fault problem that Oliver found

-added a bunch of new unit tests, including some multi-thread ones which
exercise various timing permutations.

-added support for automatic conversions of types which are
assignable, as discussed with Frank...ie:
promise<int> p;
future<long> lf(p);
future<unsigned char> ucf(p);

I learned a lot from Frank's libpoet implementation for this typing magic, but
tried to do things a bit tighter.  There is no future "proxying" or "chaining"
of futures, per se, instead all future references point to the same
implementation object under the hood, but do abstract the actual
retrieval of the value. The effect is largely the same. The promise/future
split helps a lot.

I haven't done the same assignment type conversions to the promise class
yet, but I suppose I should.

Braddock Gaskill
Dockside Vision Inc



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Kowalke Oliver (QD IT PA SI)]

Hello Braddock,

> There is a new version of my future implementation at:
> http://braddock.com/~braddock/future/
>
> CHANGES:
> -fixed this seg-fault problem that Oliver found
>
> -added a bunch of new unit tests, including some multi-thread
> ones which exercise various timing permutations.
>
> -added support for automatic conversions of types which are
> assignable, as discussed with Frank...ie:
> promise<int> p;
> future<long> lf(p);
> future<unsigned char> ucf(p);
>
> I learned a lot from Frank's libpoet implementation for this
> typing magic, but tried to do things a bit tighter.  There is
> no future "proxying" or "chaining"
> of futures, per se, instead all future references point to
> the same implementation object under the hood, but do
> abstract the actual retrieval of the value. The effect is
> largely the same. The promise/future split helps a lot.
>
> I haven't done the same assignment type conversions to the
> promise class yet, but I suppose I should.
>
> Braddock Gaskill
> Dockside Vision Inc

Thanks!

I still believe that futures should be combinable via operator&& and
operator|| - for users of the boost::future library is it more intuitive
that the resulting future of an future comination contains the result
instead of future<bool> and be force to check all related futures for
their return status and return value.
I would prefer following syntax:

promise< T1 > p1;
future< T1 > f1( p1);
promise< T2 > p2;
future< T2 > f2( p2);
promise< T3 > p3;
future< T3 > f3( p3);

future< tuple< T1, T2, T3 > f( f1 && f2 && f3);
future< variant< T1, T2, T3 > f( f1 || f2 || f3);
future< tuple< T1, T2, T3 > f( f1 && f2 && f3);
future< variant< tuple< T1, T2>, T3 > f( f1 && f2 || f3);

as Hartmut suggested.

regards, Oliver

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

On Fri, 16 Mar 2007 08:23:38 +0100, Oliver.Kowalke wrote:
> I still believe that futures should be combinable via operator&& and
> operator|| - for users of the boost::future library is it more intuitive

I'm open to this idea - just waiting for the dust to settle on exactly how it
should work.  If you make real-life use of these composition operators, you
could help with your most complex real-life usage example.

braddock

> that the resulting future of an future comination contains the result
> instead of future<bool> and be force to check all related futures for
> their return status and return value.
> I would prefer following syntax:
>
> promise< T1 > p1;
> future< T1 > f1( p1);
> promise< T2 > p2;
> future< T2 > f2( p2);
> promise< T3 > p3;
> future< T3 > f3( p3);
>
> future< tuple< T1, T2, T3 > f( f1 && f2 && f3);
> future< variant< T1, T2, T3 > f( f1 || f2 || f3);
> future< tuple< T1, T2, T3 > f( f1 && f2 && f3);
> future< variant< tuple< T1, T2>, T3 > f( f1 && f2 || f3);
>
> as Hartmut suggested.
>
> regards, Oliver
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Kowalke Oliver (QD IT PA SI)]

> I'm open to this idea - just waiting for the dust to settle
> on exactly how it should work.  If you make real-life use of
> these composition operators, you could help with your most
> complex real-life usage example.
> braddock

I suggest that

future< tuple< T1, T2, T3 > > f_and( f1 && f2 && f3);
future< variant< T1, T2, T3 > > f_or( f1 || f2 || f3);

behave like ordinary futures f1, f2, f3.
That means the the current thread is blocked in future< T >::get() not
in the ctor.

What happens in exceptional cases?
I would prefer that I get the ability to check which future (f1, f2, f3)
failed and which exception was thrown.

Oliver
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

On Wed, 14 Mar 2007 22:48:31 +0200, Peter Dimov wrote:
> As for operator&&, it doesn't deliver any extra functionality. Instead of
> wating for f1 && f2, you just wait for f1, then f2:
>
> future<int> f1 = fork( f, x );
> future<int> f2 = fork( f, y );
>
> std::cout << f1 + f2 << std::endl;

I gotta say I'm hard-pressed to think of a real-life situation where this is
not a sufficient replacement for operator&&.

operator|| still has merit though - how would you see that working with
implicitly convertible/blocking futures as proposed?  Or would it just
have to be dropped?

-braddock


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost