Review Request: future library (Gaskill version)

[Kowalke Oliver (QD IT PA SI)]

Hello,
is it correct that user defined exceptions thrown by the defered function object will be rethrown as as std::runtime_error (if it was derived from std::exception) or std::bad_exception?
If yes - what about specifying an mpl::vector with user defined exception types (passing to future_wrapper etc.)?
regards, oliver

> I wanted to formally request a review of my Futures library.
> Latest Version: http://braddock.com/~braddock/future/
>
> The library has matured greatly over the past year.  It has
> been heavily used as a key component in a mid-sized
> commercial application on both Linux and Windows.  Extensive
> unit tests and (just
> now) documentation have been written - in fact there are more
> than twice as many lines of test code and documentation than
> are in the library proper.
>
> The library incorporates many ideas from this list, from
> other prospective submissions, other languages, and from
> academic papers.
>
> The library does not currently use jamfiles or boostdoc (I
> tried I really did).  It is a header-only library.  The
> documentation is currently straight HTML, and should be very
> easy to translate to boostdoc if the submission looks good.
>
> NOTE - to avoid confusion, note that there is an older 2005
> boost.future candidate in the vault by Thorsten Schuett that
> is not related to mine (although it was studied early on).
>
> Thanks,
> Braddock Gaskill
> braddock@...
>
> _______________________________________________
> 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)]

Sorry - didn't read your docu carefully. As you say in the docs 'However, arbitrary user-defined exception types cannot be supported.'.

What about to specify an mpl::vector with arbitrary user-defined exception types?
I'm using your future library siunce last year with this little modification (at least for me it works).
Oliver

template<
     typename R,
     typename V = mpl::vector<>
  >
  class future_wrapper
  {
    public:
      future_wrapper(const boost::function<R (void)> &fn, const promise<R> &ft ) : fn_(fn), ft_(ft) {}; // stores fn and ft
      void operator()() throw() { // executes fn() and places the outcome into ft

            typedef typename boost::mpl::fold<
                V,
                detail::exec_function,
                detail::catch_exception< boost::mpl::_1, boost::mpl::_2 >
            >::type             exec_type;

           detail::catch_ellipsis< exec_type >::exec( fn_, ft_);
      }
    private:
      boost::function<R (void)> fn_;
      promise<R> ft_;
  };


struct exec_function
        {
                template< typename R >
                static void exec(
                        boost::function< R ( void) > const& fn,
                        boost::promise< R > & ft)
                { ft.set( fn() ); }

                static void exec(
                        boost::function< void ( void) > const& fn,
                        boost::promise< void > & ft)
                {
                        fn();
                        ft.set();
                }
        };

        template<
                typename P,
                typename E
        >
        struct catch_exception
        {
                template< typename R >
                static void exec(
                        boost::function< R ( void) > const& fn,
                        boost::promise< R > & ft)
                {
                        try
                        { P::exec( fn, ft); }
                        catch ( E const& e)
                        { ft.set_exception( e); }
                }

                static void exec(
                        boost::function< void ( void) > const& fn,
                        boost::promise< void > & ft)
                {
                        try
                        { P::exec( fn, ft); }
                        catch ( E const& e)
                        { ft.set_exception( e); }
                }
        };

        template< typename P >
        struct catch_ellipsis
        {
                template< typename R >
                static void exec(
                        boost::function< R ( void) > const& fn,
                        boost::promise< R > & ft)
                {
                        try
                        { P::exec( fn, ft); }
                        catch (...)
            { ft.set_exception(boost::detail::current_exception() ); }
                }

                static void exec(
                        boost::function< void ( void) > const& fn,
                        boost::promise< void > & ft)
                {
                        try
                        { P::exec( fn, ft); }
                        catch (...)
            { ft.set_exception(boost::detail::current_exception() ); }
                }
        };

> Hello,
> is it correct that user defined exceptions thrown by the
> defered function object will be rethrown as as
> std::runtime_error (if it was derived from std::exception) or
> std::bad_exception?
> If yes - what about specifying an mpl::vector with user
> defined exception types (passing to future_wrapper etc.)?
> regards, oliver
>
> > I wanted to formally request a review of my Futures library.
> > Latest Version: http://braddock.com/~braddock/future/
> >
> > The library has matured greatly over the past year.  It has been
> > heavily used as a key component in a mid-sized commercial
> application
> > on both Linux and Windows.  Extensive unit tests and (just
> > now) documentation have been written - in fact there are more than
> > twice as many lines of test code and documentation than are in the
> > library proper.
> >
> > The library incorporates many ideas from this list, from other
> > prospective submissions, other languages, and from academic papers.
> >
> > The library does not currently use jamfiles or boostdoc (I tried I
> > really did).  It is a header-only library.  The documentation is
> > currently straight HTML, and should be very easy to translate to
> > boostdoc if the submission looks good.
> >
> > NOTE - to avoid confusion, note that there is an older 2005
> > boost.future candidate in the vault by Thorsten Schuett that is not
> > related to mine (although it was studied early on).
> >
> > Thanks,
> > Braddock Gaskill
> > braddock@...
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
> _______________________________________________
> 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)]

Hello Braddock,
where does the code below block? I believe in boost::bind(Add, fa, 3) where fa is inplizitly converted to an int - right?
So JobQueue::schedule is executed only if fa got an value assigned?!

future<int> fb = q.schedule<int>(boost::bind(Add, fa, 3), fa); // fa + 3

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

[Vicente Botet Escriba]

Hi Olivier,

This is very elegant on the context of the future library.

I was thinking on some kind of mpl generation for the exception_ptr library
but I didn't thounk to wrappe the call.

----- Original Message -----
From: "Kowalke Oliver (QD IT PA AS)" <Oliver.Kowalke@...>
To: <boost@...>
Sent: Monday, April 14, 2008 9:26 AM
Subject: Re: [boost] Review Request: future library (Gaskill version)


> Sorry - didn't read your docu carefully. As you say in the docs 'However,
> arbitrary user-defined exception types cannot be supported.'.
>
> What about to specify an mpl::vector with arbitrary user-defined exception
> types?
> I'm using your future library siunce last year with this little
> modification (at least for me it works).
> Oliver
>

> template<
>     typename R,
>     typename V = mpl::vector<>
>  >
>  class future_wrapper
>  {
>    public:
>      future_wrapper(const boost::function<R (void)> &fn, const promise<R>
> &ft ) : fn_(fn), ft_(ft) {}; // stores fn and ft
>      void operator()() throw() { // executes fn() and places the outcome
> into ft
>
>            typedef typename boost::mpl::fold<
>                V,
>                detail::exec_function,
>                detail::catch_exception< boost::mpl::_1, boost::mpl::_2 >
>            >::type             exec_type;
>
>           detail::catch_ellipsis< exec_type >::exec( fn_, ft_);
>      }
>    private:
>      boost::function<R (void)> fn_;
>      promise<R> ft_;
>  };
>
>
> struct exec_function
>        {
>                template< typename R >
>                static void exec(
>                        boost::function< R ( void) > const& fn,
>                        boost::promise< R > & ft)
>                { ft.set( fn() ); }
>
>                static void exec(
>                        boost::function< void ( void) > const& fn,
>                        boost::promise< void > & ft)
>                {
>                        fn();
>                        ft.set();
>                }
>        };
>
>        template<
>                typename P,
>                typename E
>        >
>        struct catch_exception
>        {
>                template< typename R >
>                static void exec(
>                        boost::function< R ( void) > const& fn,
>                        boost::promise< R > & ft)
>                {
>                        try
>                        { P::exec( fn, ft); }
>                        catch ( E const& e)
>                        { ft.set_exception( e); }
>                }
>
>                static void exec(
>                        boost::function< void ( void) > const& fn,
>                        boost::promise< void > & ft)
>                {
>                        try
>                        { P::exec( fn, ft); }
>                        catch ( E const& e)
>                        { ft.set_exception( e); }
>                }
>        };
>
>        template< typename P >
>        struct catch_ellipsis
>        {
>                template< typename R >
>                static void exec(
>                        boost::function< R ( void) > const& fn,
>                        boost::promise< R > & ft)
>                {
>                        try
>                        { P::exec( fn, ft); }
>                        catch (...)
>            { ft.set_exception(boost::detail::current_exception() ); }
>                }
>
>                static void exec(
>                        boost::function< void ( void) > const& fn,
>                        boost::promise< void > & ft)
>                {
>                        try
>                        { P::exec( fn, ft); }
>                        catch (...)
>            { ft.set_exception(boost::detail::current_exception() ); }
>                }
>        };
>
>> Hello,
>> is it correct that user defined exceptions thrown by the
>> defered function object will be rethrown as as
>> std::runtime_error (if it was derived from std::exception) or
>> std::bad_exception?
>> If yes - what about specifying an mpl::vector with user
>> defined exception types (passing to future_wrapper etc.)?
>> regards, oliver

I see only a problem: the interface of the future_wrapper is changed.

Maybe something like
    template<
        typename R,
        typename V = BOOST_EXCEPTION_PTR_USER_EXCEPTION_VECTOR
    class future_wrapper ...

allow to preserv the interface.

Another problem is that we need to do the same for each class using the
exception_ptr library.

It will be nice if the exec_function, the catch_exception and the
catch_ellipsis do not depend directly on the promise<R>. I don't know if it
is possible to make a wrap_call template with a template parameter Promise
and having these three classes nested.

template <class template<class> PromiseTmpl>
struct wrap_call {
    struct exec_function
    {
        template< typename R, class Policy= promise_policy< PromiseTmpl< R >
 > >
        static void exec(
            boost::function< R ( void) > const& fn,
            PromiseTmpl< R > & ft)
                { Policy::set(ft,  fn() ); }
        // ...

    template <
        typename V = BOOST_EXCEPTION_PTR_USER_EXCEPTION_VECTOR
    >
    struct call {
        typedef typename boost::mpl::fold<
                    V,
                    wrap_call<PromiseTmpl>::exec_function,
                    wrap_call<PromiseTmpl>::catch_exception< boost::mpl::_1,
boost::mpl::_2 >
                >::type             exec_type;

        typedef wrap_call<PromiseTmpl>::catch_ellipsis< exec_type > type;
    };
}

A policy class should be needed to take care of the promise concept
interface

template <class Promise>
struct promise_policy  {
    void set(Promise& p, const R &v) {p.set(v);}
    void set_exception(Promise& p, const exception_ptr&e)
{p.set_exception(e);}
};

And use it as follows
    template<
        typename R,
        typename V = BOOST_EXCEPTION_PTR_USER_EXCEPTION_VECTOR
    class future_wrapper {
         // ...
         future_wrapper(const boost::function<R (void)> &fn, const
promise<R> &ft ) : fn_(fn), ft_(ft) {}; // stores fn and ft
         void operator()() throw() { // executes fn() and places the outcome
into ft

               exception_ptr::wrap_call<promise>::call<V>::exec( fn_, ft_);

        }
         // ...

Do you think that this could work?

Best
_____________________
Vicente Juan Botet Escriba


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

[Kowalke Oliver (QD IT PA SI)]

Hello Vincente,

> This is very elegant on the context of the future library.

thank you :))

> It will be nice if the exec_function, the catch_exception and
> the catch_ellipsis do not depend directly on the promise<R>.

If desired I would suggest that exception_ptr will handle arbitrary user-defined
exception types. The function detail::_exp_current_exception (I'm refering to exception_ptr_impl.hpp from Braddogs future library) mußt be a template which gets the arbitrary user-defined exception types as tempalte arguments. I append a first shot of the code (modified versions of future and exception_ptr):

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

#include <boost/bind.hpp>
#include <boost/mpl/vector.hpp>
#include <boost/thread.hpp>

#include <future.hpp>

struct X
{
        std::string msg;

        X( std::string const& msg_)
        : msg( msg_)
        {}
};

int add( int a, int b)
{ throw X("abc"); return a + b; }

void execute( boost::function< void() > fn)
{ fn(); }

int main( int argc, char *argv[])
{
        try
        {
                boost::promise< int > p;
                boost::future_wrapper< int, boost::mpl::vector< X > > wrapper(
                         boost::bind(
                                add,
                                11,
                                13),
                        p);
                boost::future< int > f( p);

                boost::thread t(
                        boost::bind(
                                & execute,
                                wrapper) );

                std::cout << "add = " << f.get() << std::endl;

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





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

[Kowalke Oliver (QD IT PA SI)]

the code works at least with gcc 4.2.3
Oliver

> #include <iostream>
> #include <cstdlib>
> #include <stdexcept>
>
> #include <boost/bind.hpp>
> #include <boost/mpl/vector.hpp>
> #include <boost/thread.hpp>
>
> #include <future.hpp>
>
> struct X
> {
>         std::string msg;
>
>         X( std::string const& msg_)
>         : msg( msg_)
>         {}
> };
>
> int add( int a, int b)
> { throw X("abc"); return a + b; }
>
> void execute( boost::function< void() > fn) { fn(); }
>
> int main( int argc, char *argv[])
> {
>         try
>         {
>                 boost::promise< int > p;
>                 boost::future_wrapper< int,
> boost::mpl::vector< X > > wrapper(
>                          boost::bind(
>                                 add,
>                                 11,
>                                 13),
>                         p);
>                 boost::future< int > f( p);
>
>                 boost::thread t(
>                         boost::bind(
>                                 & execute,
>                                 wrapper) );
>
>                 std::cout << "add = " << f.get() << std::endl;
>
>                 return EXIT_SUCCESS;
>         }
>         catch ( X const& x)
>         { std::cerr << x.msg << std::endl; }
>         catch ( std::exception const& e)
>         { std::cerr << e.what() << std::endl; }
>         catch ( ... )
>         { std::cerr << "unhandled exception" << std::endl; }
>         return EXIT_FAILURE;
> }
>
>

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

[Vicente Botet Escriba]

Some minor modifications to the backdoor friend declaration
----- Original Message -----
From: "vicente.botet" <vicente.botet@...>
To: <boost@...>
Sent: Monday, April 14, 2008 2:56 AM
Subject: Re: [boost] Review Request: future library (Gaskill version)

> Hello Gaskill,
>
> From: "Braddock Gaskill" <braddock@...>
> To: <boost@...>
> Sent: Monday, April 14, 2008 12:55 AM
> Subject: Re: [boost] Review Request: future library (Gaskill version)
>
>
> <snip>
>
>>> 2. What is the motivation for allowing more than one callback? This
>>> turns
>>> the promise into a signal.
>>
>> Hehe, I go back and forth on one or many callbacks every time I revisit
>> the
>> design - last time being last week.
>>
>> My justification is that add_callback() is really needed for authors of
>> other frameworks to hook into things (see prior post on guards and
>> operators).  My fear with only one callback is that, for example,
>> ASIO adds future support, uses add_the_callback internally, and later a
>> user of ASIO uses add_the_callback for his own purposes and breaks
>> ASIO.
>>
>> I have considered making add_callback a friend function in a separate
>> future_ext.hpp header just to distance it from standard future<> usage.
>> It
>> is really only necessary to make the library extensible.
>
> I use to put these kind of interfaces in a backdoor class which is a
> friend
> class .
> This pattern was already used by the thread class in order to separate the
> safe interface(scoped_lock) and the unsafe one(lock/unlock), but was this
> backdoor was on a detail namespace and not in the public interface). The
> new
> thread library do not contains nymore this indirection.
>
> The user of the library is not aware of this interface, but the author of
> other library will use this backdoor class knowing that the door it opens
> is
> a little bit more risky or unsafe and need a careful usage.
>
>  template<typename R> class future
>  {
>     // ...

        typedef future_backdoor<R> backdoor;

>   private:

        friend class backdoor;

>       callback_reference add_callback(const boost::function<void (void)>
> &f);
>       void remove_callback(callback_reference &ref);
>    }
>
> // future_backdoor.hpp
>
> // ...
>
>  template<typename R> class future_backdoor {
>    future<R>& fut_;
>  public:
>        future_backdoor(future<R>& fut): fut_(fut){}
>        callback_reference add_callback(const boost::function<void (void)>
> &f) {return fut_.add_callback(f)}
>        void remove_callback(callback_reference &ref) {return
> fut_.remove_callback(ref)}
>  }
>
> The aware user could use this as follows:
>
>    future<T> fut;
>    //...
>    future_backdoor<T> bd_fut(fut);

or
      future<T>::backdoor bd_fut(fut);

>    bd_fut.add_callback(f);
>
> or directly
>
>    future_backdoor<T>(fut).add_callback(f);

or
      future<T>::backdoor(fut).add_callback(f);

> future_backdoor behaves like unsafe cast, a little bit as for example
> const_cast.
>
> What do you think?
>

---------------------------
Vicente Juan Botet Escriba


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

[braddock]

On Mon, 14 Apr 2008 09:58:52 +0200, Kowalke Oliver (QD IT PA AS) wrote:
> where does the code below block? I believe in boost::bind(Add, fa, 3)
> where fa is inplizitly converted to an int - right? So
> JobQueue::schedule is executed only if fa got an value assigned?!
>
> future<int> fb = q.schedule<int>(boost::bind(Add, fa, 3), fa); // fa + 3

Hi Oliver,
It doesn't block.  This is code from the
"Guards" section of my documentation - the schedule() method is modified
to accept a future<T> as the second argument for use as a guard.

fa is not implicitly converted to an int (and does not block), because the
second schedule() arg is in the context of a future<int>.

fa is also not implicitly converted to an int within the bind, because the
bind is templated such that it gladly accepts fa as a future<int>
without forcing it into an int context until the function is called.

The guard magic comes from the change we made to the schedule() method just
before that example - so that the job is not REALLY scheduled until fa
(the guard) is fulfilled (via a callback).

The following code does not dead-lock, for example:

  promise<int> p9;
  future<int> f9(p9);
  future<int> f8 = q.schedule<int>(boost::bind(Add, f9, 3), f9); //no block
  p9.set(99); // we still get here without a deadlock block
  assert(f8.get() == 102);

future/example1.cpp contains all of the example code from the
documentation if you actually want to build it.

The lack of clarity is certainly yet another argument for getting rid of
the implicit conversion method, though.  If no one speaks up in it's
defense soon I'm likely to axe implicit conversion.

-braddock

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

[braddock]

On Mon, 14 Apr 2008 09:26:07 +0200, Kowalke Oliver (QD IT PA AS) wrote:
> What about to specify an mpl::vector with arbitrary user-defined exception types?
> I'm using your future library siunce last year with this little modification (at least for me it works).

I really want to improve the handling of arbitrary user-defined exceptions,
and this looks at first glance like just the ticket!

I'll definitely take a close look at this (no time to refresh my mpl
tonight).

   -braddock

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

[Kowalke Oliver (QD IT PA SI)]

Is there a schedule for a review of this library?

> I wanted to formally request a review of my Futures library.
> Latest Version: http://braddock.com/~braddock/future/
>
> The library has matured greatly over the past year.  It has
> been heavily used as a key component in a mid-sized
> commercial application on both Linux and Windows.  Extensive
> unit tests and (just
> now) documentation have been written - in fact there are more
> than twice as many lines of test code and documentation than
> are in the library proper.
>
> The library incorporates many ideas from this list, from
> other prospective submissions, other languages, and from
> academic papers.
>
> The library does not currently use jamfiles or boostdoc (I
> tried I really did).  It is a header-only library.  The
> documentation is currently straight HTML, and should be very
> easy to translate to boostdoc if the submission looks good.
>
> NOTE - to avoid confusion, note that there is an older 2005
> boost.future candidate in the vault by Thorsten Schuett that
> is not related to mine (although it was studied early on).
>
> Thanks,
> Braddock Gaskill
> braddock@...
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

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

[Ronald Garcia]

Hi Braddock,

I have recieved your request and have added the Futures library to  
the review queue.

Cheers,
ron

On Apr 9, 2008, at 9:39 PM, Braddock Gaskill wrote:

> I wanted to formally request a review of my Futures library.
> Latest Version: http://braddock.com/~braddock/future/
>
> The library has matured greatly over the past year.  It has been  
> heavily
> used as a key component in a mid-sized commercial
> application on both Linux and Windows.  Extensive unit tests and (just
> now) documentation have been written - in fact there are more than  
> twice
> as many lines of test code and documentation than are in the library
> proper.
>
> The library incorporates many ideas from this list, from other  
> prospective
> submissions, other languages, and from academic papers.
>
> The library does not currently use jamfiles or boostdoc (I tried I  
> really
> did).  It is a header-only library.  The documentation is currently
> straight HTML, and should be very easy to translate to boostdoc if the
> submission looks good.
>
> NOTE - to avoid confusion, note that there is an older 2005  
> boost.future
> candidate in the vault by Thorsten Schuett that is not related to mine
> (although it was studied early on).
>
> Thanks,
> Braddock Gaskill
> braddock@...
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/ 
> listinfo.cgi/boost

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

[Anthony Williams-3]

Braddock Gaskill <braddock@...> writes:

> On Thu, 10 Apr 2008 21:53:33 +0200, vicente.botet wrote:
>> How do your library positions with respect to the standard proposals?
>> N2561 Anthony Williams: An Asynchronous Future Value
>
> I've now taken a good look at the recent C++0X N2561 "An Asynchronous Future
> Value" proposal.

Thanks for your comments. I'll try and incorporate them in an updated paper.

Anthony
--
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

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

[Anthony Williams-3]

Hi all,

Having just uploaded my prototype of N2561 futures to my website, I would like
it to be considered for review alongside Braddock Gaskill's version. It is not
as rich in features as Braddock's version, but this is the current proposal
before the C++ committee. I intend to update the proposal in time for the next
committee mailing, which is 16th May, so would be grateful if people could
comment before then, even if we don't get a formal review. It currently
requires the boost trunk.

http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2561.html

Anthony
--
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

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

[Vicente Botet Escriba]

Hi,

why we don't need to protect get_future() function of multiple thread
access?

        // Result retrieval
        unique_future<R> get_future()
        {
            if(!future)
            {
                throw future_moved();
            }
            if(future_obtained)
            {
                throw future_already_retrieved();
            }
            future_obtained=true;
            return unique_future<R>(future);
        }
Best
_____________________
Vicente Juan Botet Escriba

----- Original Message -----
From: "Anthony Williams" <anthony_w.geo@...>
To: <boost@...>
Sent: Monday, May 05, 2008 10:41 AM
Subject: [boost] Review Request: future library (N2561/Williams version)

> Hi all,
>
> Having just uploaded my prototype of N2561 futures to my website, I would
> like
> it to be considered for review alongside Braddock Gaskill's version. It is
> not
> as rich in features as Braddock's version, but this is the current
> proposal
> before the C++ committee. I intend to update the proposal in time for the
> next
> committee mailing, which is 16th May, so would be grateful if people could
> comment before then, even if we don't get a formal review. It currently
> requires the boost trunk.
>
> http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2561.html
>
> Anthony
> --
> Anthony Williams            | Just Software Solutions Ltd
> Custom Software Development | http://www.justsoftwaresolutions.co.uk
> Registered in England, Company Number 5478976.
> Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

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

[Anthony Williams-3]

"vicente.botet" <vicente.botet@...> writes:

> why we don't need to protect get_future() function of multiple thread
> access?

By design you can only call this function once, so if multiple threads called
it concurrently and that was safe, only one would get the future, and the
other would get an exception. The user should therefore use appropriate
synchronization to ensure correct results anyway, so making this call
thread-safe would not be of benefit.

Anthony
--
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

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

[Johan Torp]

I haven't downloaded and compared your and Anthony's implementation yet so forgive me if I misunderstand anything.

Braddock Gaskill-2 wrote:

1) First - future<T>::add_callback(f).  

add_callback is a hook called when the future is fulfilled.  End
users probably shouldn't have to touch it, but framework authors (who
write schedulers, asio, co-routines, etc) will DEFINITELY need it.  

add_callback() enables the following:

-Future Operators ((f1 && f2) || (f3 && f2) etc) - With add_callback, custom
future_operators can be written by users.

Isn't it more natural to consider the promise object a signal and the future object a slot?
If we exposed a mechanism to wait for multiple promises we could implement promise operators instead. ((p1 && p2) || (p3 && p2) would create a new promise which internally listens to multiple promises. A binary future which takes two promises and a binary operator would be enough for this example. For efficiency reasons we'd probably need some mechanism which can add arbitrarily many promises at runtime.

Braddock Gaskill-2 wrote:

2) Second - Lazy Futures.  

This would correspond to lazy promises.


Best Regards, Johan

[Johan Torp]

I've downloaded and started looking at your implementation. Well actually, I already use a part of it in my job :)

Please disregard my previous reply - I realize now we don't want to require users to have access to the promises to create compound futures.

Braddock Gaskill-2 wrote:

I'm disregarding the future C++ move semantics, of course.  
We need a future<C++0x>::wait() for that... :)

unique_future<T> is an interesting concept.  Still wrapping my head around that.

Still, boost::future might be a too general name if we believe C++0x
will provide both a reference semantics and a move semantics future object.

Braddock Gaskill-2 wrote:

My base classes offer two features which N2561 does not (and which I would
really hope to see in any C++0X standard).

1) First - future<T>::add_callback(f).  

Exposing this in the interface poses two problems:
1. If any of the callbacks raises an exception it will be forwarded to the promise-fulfilling thread.
2. remove_callback cannot be implemented "instantly" in a dead-lock safe manner. User code which returns from remove_callback() will still need to be prepared for callbacks.

I agree with you that the functionality is _very_ useful.
Have you considered implementing a future-intrusive mechanism to wait for multiple futures instead? This way a separate waiting thread would be needed - but isn't that the desired use case?
You probably need to be able to wait until either any or all of a dynamically created group of futures are ready. Future return value composition, for instance operators && and ||, might be nice to support but will probably require a great deal of thought.

Braddock Gaskill-2 wrote:

2) Second - Lazy Futures.  

This is something I picked up from the Oz language future implementation, and
have found very useful.  A Lazy Future essentially flags itself when it is
"needed" - ie, when someone is blocked on a f.wait(), and f.get(), or has
explicitly called "f.set_is_needed()".  This allows, for example, a task to
only process _IF_ the result is actually needed.  

Do we really want to use the future value as a parallel programming primitive?
I haven't read about lazy future streams yet but my initial instinct is a fear of making the future object
the solution to everything.

Introducing "is_needed" couples future-listeners and promise-fulfillers.
If I had a const promise reference I'd expect to be able to create a temporary future, query it and then destroy it. With lazy futures, the lifetime of futures start to matter in implicit ways which might not be obvious to the "future using part" of the code.

Analogously I think it would be strange if a broadcaster chose to not do something because nobody was listening or if an observable in the observer-observable pattern changed it's behaviour if it wasn't observed.

Still, the concept might be transparent and useful enough. I need to read up future streams and other applications some more.


Best Regards, Johan

[Vicente Botet Escriba]

----- Original Message -----
From: "Anthony Williams" <anthony_w.geo@...>
To: <boost@...>
Sent: Tuesday, May 06, 2008 8:42 AM
Subject: Re: [boost] Review Request: future library (N2561/Williams version)

> "vicente.botet" <vicente.botet@...> writes:
>
>> why we don't need to protect get_future() function of multiple thread
>> access?
>
> By design you can only call this function once, so if multiple threads
> called
> it concurrently and that was safe, only one would get the future, and the
> other would get an exception. The user should therefore use appropriate
> synchronization to ensure correct results anyway, so making this call
> thread-safe would not be of benefit.
>

I don't understand the need of this function. Could you show a use case for
promise::get_future() function?


_____________________
Vicente Juan Botet Escriba


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

[Anthony Williams-3]

"vicente.botet" <vicente.botet@...> writes:

> ----- Original Message -----
> From: "Anthony Williams" <anthony_w.geo@...>
> To: <boost@...>
> Sent: Tuesday, May 06, 2008 8:42 AM
> Subject: Re: [boost] Review Request: future library (N2561/Williams version)
>
>
>> "vicente.botet" <vicente.botet@...> writes:
>>
>>> why we don't need to protect get_future() function of multiple thread
>>> access?
>>
>> By design you can only call this function once, so if multiple threads
>> called
>> it concurrently and that was safe, only one would get the future, and the
>> other would get an exception. The user should therefore use appropriate
>> synchronization to ensure correct results anyway, so making this call
>> thread-safe would not be of benefit.
>>
>
> I don't understand the need of this function. Could you show a use case for
> promise::get_future() function?

promise::get_future() is the only way to get a future from a promise. Since
the whole point of using promise is to get the future, it's rather pointless
without it.

Were you getting at something else?

Anthony
--
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

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

[Vicente Botet Escriba]

----- Original Message -----
From: "Anthony Williams" <anthony_w.geo@...>
To: <boost@...>
Sent: Thursday, May 08, 2008 2:35 PM
Subject: Re: [boost] Review Request: future library (N2561/Williams version)

> "vicente.botet" <vicente.botet@...> writes:
>
>> ----- Original Message -----
>> From: "Anthony Williams" <anthony_w.geo@...>
>> To: <boost@...>
>> Sent: Tuesday, May 06, 2008 8:42 AM
>> Subject: Re: [boost] Review Request: future library (N2561/Williams
>> version)
>>
>>
>>> "vicente.botet" <vicente.botet@...> writes:
>>>
>>>> why we don't need to protect get_future() function of multiple thread
>>>> access?
>>>
>>> By design you can only call this function once, so if multiple threads
>>> called
>>> it concurrently and that was safe, only one would get the future, and
>>> the
>>> other would get an exception. The user should therefore use appropriate
>>> synchronization to ensure correct results anyway, so making this call
>>> thread-safe would not be of benefit.
>>>
>>
>> I don't understand the need of this function. Could you show a use case
>> for
>> promise::get_future() function?
>
> promise::get_future() is the only way to get a future from a promise.
> Since
> the whole point of using promise is to get the future, it's rather
> pointless
> without it.

why this is not an internal feautre?

> Were you getting at something else?

Sorry, but I thouth that it is up to the promise to communicate with his
future when the user do a set_value or set_exception or elsewhere

When the user will need the future of a promise?

Vicente


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