[futures] composite or

[braddock]

On Fri, 16 Mar 2007 06:03:14 -0400, Braddock Gaskill wrote:

> 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&&.

Actually, I retract that.  Once you have an ||, then you need an && if you want
to do:

f = f1 || (f2 && f3); //assuming no implicit block-and-convert syntax
f.wait();



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

[Timmo Stange]

Peter Dimov wrote:

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

That's excellent news. Has anyone started on a boostification of that
with support for real hardware targets (i.e. processor memory barriers)?

Regards

Timmo Stange

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

[Peter Dimov]

Timmo Stange wrote:
> Peter Dimov wrote:
>
>> N2195, Proposed Text for Chapter 29, Atomic Operations Library
>> [atomics]
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2195.html 
>
> That's excellent news. Has anyone started on a boostification of that
> with support for real hardware targets (i.e. processor memory
> barriers)?

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

[Hartmut Kaiser]

 
Oliver.Kowalke@... wrote:

> 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.

Sure, that's the exact behavior of the future's library in the Vault.

> 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.

Agreed. I still think the behavior wrt exceptions should be controllable by
a policy.

Regards Hartmut
 

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

[Frank Mori Hess]

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

On Friday 16 March 2007 03:23 am, 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
> 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've clearly failed to communicate my criticisms clearly.  I was not
presenting an alternate syntax for the future combination functions.  I
was presenting another function with semantics that bear no direct
relation to the combination functions, but whose prototype would conflict
with the proposed use of operator|| and && for the combination functions.

Maybe it would have been clearer if I had said

future<bool> operator||(const future<bool> &, const future<bool>&);

I was not objecting to the functionality of combining futures (I don't
really have an opinion on that) I was objecting to the choice of
overloading operators instead of using normal function names.

To a user of libpoet, where the correspondence between futures and their
values is emphasized, seeing something like

future_a || future_b

in code, the principle of least surprise would  lead them to guess that the
meaning of the overloaded operation would be to return a future whose
value corresponded to applying logical or to the values of future_a and
future_b.  This behaviour would correspond to an active_function created
from the ordinary operator|| acting on values.

The confusion only underscores my point.  Overloading a function name (or
operator) with multiple functions that bear no direct semantic
relationship to each other is merely confusing.  The namespace for
possible operators is extremely limited.  Unfortunately, this seems to
make everyone with a neat idea want to overload an operator with it, so
that everyone notices their function and is more likely to use it.

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

iD8DBQFF+pLk5vihyNWuA4URAsFfAKC40HgefbbOcYUvuPItqIxO4+6jEgCg4uMW
dwoS6I+e1t3oWN8gbnCmDCk=
=9llc
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Frank Mori Hess]

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

On Thursday 15 March 2007 23:30 pm, Braddock Gaskill wrote:
> 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.

Is this an implementation detail, or does it change the semantics?  For
example, if I the class A is convertible to B and B is convertible to C,
but A is not directly convertible to C, can I get a future<C> from a
future<A> by going through a future<B> as an intermediary?  Or would it
try (and fail) to convert the A value directly to a C value?

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

iD8DBQFF+pvx5vihyNWuA4URAsKIAKDgi9ekzMWX3+znwUPbNG3jT0c/tACcDvnn
L9nZ2nRIBZHC3gNIR06M5sY=
=WCB8
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

On Fri, 16 Mar 2007 09:30:24 -0400, Frank Mori Hess wrote:
> On Thursday 15 March 2007 23:30 pm, Braddock Gaskill wrote:
>> 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.
>
> Is this an implementation detail, or does it change the semantics?  

Implementation detail.  Eliminates the method forwarding and signal/callback
connection/disconnection, and eliminates proxy mutexes.  Looking at your
implementation laid the groundwork though, and I'd appreciate if you could put
some eyeballs on what I did.  The split promise/future concept eliminates the
nasty setValue() error case, as I think you pointed out in an earlier post.

> example, if I the class A is convertible to B and B is convertible to C,
> but A is not directly convertible to C, can I get a future<C> from a
> future<A> by going through a future<B> as an intermediary?

This should work.  It will chain through a couple of my
detail::return_value_type_adaptor instances.  See test_future.cpp.  Not exactly
the case, but implementation-wise it is doing the same.

    void TestCase9() { // assignable, but different, types
      boost::promise<int> p;
      boost::future<long> lfut(p);
      boost::future<int>  ifut(p);
      boost::future<unsigned int> uifut = lfut;
      boost::future<unsigned char> ucfut(uifut);
      p.set(27);
      BOOST_CHECK_EQUAL(lfut.get(), 27);
      BOOST_CHECK_EQUAL(ucfut.get(), 27U);
    }

One thing I did not do (yet) was add a generic conversion function capability.
This is easily done now (in fact I did a rough cut and then removed it).
I was hoping to get at least one real-life example usage of how it is used
- say exactly how the syntax of a future<vector<T> > to future<T>
conversion might work, as you had mentioned?  

There seems to be a fine line between embedded conversion and creating a more
explicit function
future<T> element_extractor(future<vector<T> > f, int index);

Braddock Gaskill
Dockside Vision Inc



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

[Frank Mori Hess]

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

On Friday 16 March 2007 11:05 am, Braddock Gaskill wrote:
> One thing I did not do (yet) was add a generic conversion function
> capability. This is easily done now (in fact I did a rough cut and then
> removed it). I was hoping to get at least one real-life example usage of
> how it is used - say exactly how the syntax of a future<vector<T> > to
> future<T> conversion might work, as you had mentioned?

Here's an example extracting at(1) from a future vector:

poet::future<std::vector<double> > myVec;
poet::future<double> myVecElement(myVec, boost::bind<const
double&>(&std::vector<double>::at, _1, 1));

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

iD8DBQFF+sG75vihyNWuA4URAohrAJ4oXDjjZW3G6lQyh1EtYXHF0n7+kgCfZHqs
QkQyMJCkmtnEsAA0WfZbNfY=
=nkmB
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

On Fri, 16 Mar 2007 12:11:38 -0400, Frank Mori Hess wrote:

> On Friday 16 March 2007 11:05 am, Braddock Gaskill wrote:
>> One thing I did not do (yet) was add a generic conversion function
>
> Here's an example extracting at(1) from a future vector:
>
> poet::future<std::vector<double> > myVec;
> poet::future<double> myVecElement(myVec, boost::bind<const
> double&>(&std::vector<double>::at, _1, 1));

Hrm, this has profound implications.  I don't know if they are good or bad, but
they go beyond my current understanding of the future idiom.

This allows you to not just embed conversion functions, but ANY function, in
the guise of a future<T>.

future<double> func1(const future<double> &a);
future<double> func2(const future<double> &a);
future<double> func3(const future<double> &a);

promise<double> p;
future<double> f0(p);
future<double> f1(f0, func1); // f1.get() equiv to func1(f0)
future<double> f2(f1, func2); // f2.get() equiv to func2(func1(f0))

f2.get(); // Does caller realize this is actually a call to func2(func1(f0))??

future<double> f3 = std::fork(bind(&func3, f2));
// Did the author of func3() realize his call to a.get() might do _anything_?

Of course the assignable type conversions already let the cat out of the bag,
not just the generic conversion functions.  In fact, my add_callback() hook
opens a similar bag of worms for the promise::set() call.  I really only want
add_callback as a hook to allow independent event notification models and
composition to be developed on top, not for end user use.

So, good, bad, or awesome? ;)



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

[braddock]

On Fri, 16 Mar 2007 13:32:05 -0400, Braddock Gaskill wrote:
> future<double> func1(const future<double> &a);
> future<double> func2(const future<double> &a);
> future<double> func3(const future<double> &a);

My pseudo-code typing was wrong here.  I suppose it would be:
double func1(double a);
with f1.get() equiv to func1(f0.get()), etc

But you get the idea....


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

[Frank Mori Hess]

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

On Friday 16 March 2007 13:32 pm, Braddock Gaskill wrote:

> On Fri, 16 Mar 2007 12:11:38 -0400, Frank Mori Hess wrote:
> > On Friday 16 March 2007 11:05 am, Braddock Gaskill wrote:
> >> One thing I did not do (yet) was add a generic conversion function
> >
> > Here's an example extracting at(1) from a future vector:
> >
> > poet::future<std::vector<double> > myVec;
> > poet::future<double> myVecElement(myVec, boost::bind<const
> > double&>(&std::vector<double>::at, _1, 1));
>
> Hrm, this has profound implications.  I don't know if they are good or
> bad, but they go beyond my current understanding of the future idiom.

It could be implemented as a free function instead of a constructor, to
give it a little conceptual separation from the future class proper.

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

iD8DBQFF+tXe5vihyNWuA4URAquWAJ0XSmoFXp8yOGZ0a/sKqEm+GYuAGQCfQ0Pn
U3ykKs8ndzvzYX0R3m5Zxsc=
=ifdb
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[braddock]

On Fri, 16 Mar 2007 13:37:33 -0400, Frank Mori Hess wrote:
>> Hrm, this has profound implications.  I don't know if they are good or
>> bad, but they go beyond my current understanding of the future idiom.
>
> It could be implemented as a free function instead of a constructor, to
> give it a little conceptual separation from the future class proper.

Yeah, maybe I'll make a seperate "future_friends.hpp" with free functions for
adding a future callback or a general conversion function.  That way people can
sort of hook into the implementation if they are making a broader framework and
know what they are doing (like libpoet vector adaptors or compositions), but
with a clear "do not abuse this at home" banner.

I can see many interesting uses of these future adaptor functions, but at the
end of the day an object that you call to get a return value and any arbitrary
behavior is called a "functor" not a "future".

I've previously developed a sort of heavyweight future concept that
I called a "place".  I'm excited about discovering futures because they are
MORE constrained, while my "place" concept was powerful and convenient, but
always left me wondering if I'd covered every conceivable case.  I'll still be
using "place" where needed, but future everywhere else...

        -braddock


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

[Frank Mori Hess]

On Friday 16 March 2007 14:24 pm, Braddock Gaskill wrote:

> Yeah, maybe I'll make a seperate "future_friends.hpp" with free
> functions for adding a future callback or a general conversion function.
>  That way people can sort of hook into the implementation if they are
> making a broader framework and know what they are doing (like libpoet
> vector adaptors or compositions), but with a clear "do not abuse this at
> home" banner.
>
> I can see many interesting uses of these future adaptor functions, but
> at the end of the day an object that you call to get a return value and
> any arbitrary behavior is called a "functor" not a "future".

I might just drop the constructor with conversionFunction from libpoet's
future class.  The same effect can already be achieved with an
active_function, for example extraction from a future vector:

poet::future<std::vector<double> > myVecFuture(/*...*/);
poet::active_function<double (std::vector<double>, unsigned i)>
conversionFunction(boost::bind<const double&>(&std::vector<double>::at,
_1, _2));
poet::future<double> myVecElementFuture = conversionFunction(myVecFuture,
1);

It's a bit overkill to create a new thread just to extract a vector
element, but the user can keep a long-lived scheduler around for use with
trivial active_functions if they care.

--
Frank


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

[Kowalke Oliver (QD IT PA SI)]

> > 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.

It should be also possible to get the information from which future the
result is taken.

> Sure, that's the exact behavior of the future's library in the Vault.

The problem with the futures library in the vault is that sometimes it
raies an assertion - this well known by the author but he don't know why
this is raised and how to fix.

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