headers
Tom Brinkman | 6 Jan 02:25

Futures Review Starts Today - January 5, 2009

Futures Review Starts Today - January 5, 2009

Braddock Gaskill
http://braddock.com/~braddock/future

Anthony Williams
http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp

Please review one or both libraries for submission to boost.
Apparently, Anthony Williams' submission has also been
sumbitted the C++ standards committee.  Status unknown.

As always, here are some questions you might want to answer in your review(s):

What is your evaluation of the design(s)?
What is your evaluation of the implementation(s)?
What is your evaluation of the documentation?
What is your evaluation of the potential usefulness of the library(s)?
Did you try to use the library? With what compiler(s)? Did you have
any problems?
How much effort did you put into your evaluation(s)? A glance? A quick
reading? In-depth study?
Are you knowledgeable about the problem domain?
Do you think the libraries should be accepted into Boost as-is or
should they be merged?

Apparently, there has been various discussions about these two
libraries last six months.
The authors will need to bring us up to date as to why they want their libraries
to be reviewed seperately.
(Continue reading)

Permalink | Reply |
headers
Oliver Kowalke | 6 Jan 08:02

Re: Futures Review Starts Today - January 5, 2009

I'm refering to the updated version of Anthonys library at
http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html because
http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp seams not to be up-to-date
(missing some functionality like lazy futures)!

> What is your evaluation of the design(s)?
> What is your evaluation of the implementation(s)?

Both libraries are good designed and provide:
- value transfer
- exception transfer (Braddock uses its own exception_ptr implementation)
- lazy futures (result is not actually computed until it is requested via future::get() )
- a wrapper class for wrapping callable objects (future_wrapper, packaged_task)

Task chaining  - Braddocks implementation provides a callback mechanism if the future becomes ready
(result was set). This allows chaining of tasks (used in boost.threadpool). This functionality seams
not to be provided by the lib from Anthony.

Wait callbacks are provided only by Anthonys implementation.

Move semantics are only provided by Anthonys lib.

> What is your evaluation of the documentation?

Content of both documentations is sufficient - Braddock doesn't conform to the boost documentation style (Quickbook/Boostbook).

> What is your evaluation of the potential usefulness of the library(s)?

Both libaries are useful and share same functionality but also provide additional functionality (ready
callback, wait callback, move semantics).
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 6 Jan 08:19

Re: Futures Review Starts Today - January 5, 2009

Hi,
----- Original Message ----- 
From: "Tom Brinkman" <reportbase <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, January 06, 2009 2:25 AM
Subject: [boost] Futures Review Starts Today - January 5, 2009

> 
> Futures Review Starts Today - January 5, 2009
> 
> Braddock Gaskill
> http://braddock.com/~braddock/future
> 
> Anthony Williams
> http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp

As Anthony has poste to this ML 
> The latest version of that library is at:
> 
> Docs: http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html
> Code+Docs: http://www.justsoftwaresolutions.co.uk/files/n2561_futures_revised_20080530.zip
> 
> Anthony
> -- 

> Please review one or both libraries for submission to boost.
> Apparently, Anthony Williams' submission has also been
> sumbitted the C++ standards committee.  Status unknown.

Anthony Williams' submission has been accepted
(Continue reading)

Permalink | Reply |
headers
Anthony Williams | 6 Jan 10:19

Re: Futures Review Starts Today - January 5, 2009

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

> Anthony, I would prefer you propose for review the n2627
> interfacce. Why do you propose for review un interface that is
> outdated? It seems to me a lost of time.

I wrote the code for the boost submission 8-9 months ago, in
accordance with the then-current C++0x proposal (with a few extras)
and it has been in the review queue since. I have since focused my
energy on my commercial library, rather than on a library which may or
may not be accepted into Boost, with or without changes (especially
since there is a competing submission).

If a futures library is accepted into Boost, I will gladly work with
Braddock to update the library with any features required by the
review, including conformance to N2627.

Anthony
--

-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Johan Torp | 6 Jan 14:27

Re: Futures Review Starts Today - January 5, 2009


Just so that noone misses it, I submitted my review yesterday at
http://www.nabble.com/Futures---Reviews-Needed-(January-5%2C-2009)-to21221849.html

Best Regards, Johan Torp
www.johantorp.com

--

-- 
View this message in context: http://www.nabble.com/Futures-Review-Starts-Today---January-5%2C-2009-tp21303049p21310316.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 6 Jan 23:13

Re: Futures Review - minor implementation details

Hi Anthony,

Some minor implementation details:
Why there is not other.future reset in
        shared_future(shared_future && other)
        {
            future.swap(other.future);
        }
        shared_future(unique_future<R> && other)
        {
            future.swap(other.future);
        }

How the move is made?

Is 
            future.swap(other.future);
            other.future.reset();
more efficient than
            future.reset(other.future);
            other.future.reset();
? Otherwise you can change it in:

        shared_future& operator=(shared_future && other)
        {
            future.swap(other.future);
            other.future.reset();
            return *this;
        }
        shared_future& operator=(boost::detail::thread_move_t<shared_future> other)
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 10 Jan 14:25

Re: Futures Review - minor implementation details

PING!
----- Original Message ----- 
From: "vicente.botet" <vicente.botet <at> wanadoo.fr>
To: <boost <at> lists.boost.org>
Sent: Tuesday, January 06, 2009 11:13 PM
Subject: Re: [boost] Futures Review - minor implementation details

> 
> Hi Anthony,
> 
> Some minor implementation details:
> Why there is not other.future reset in
>        shared_future(shared_future && other)
>        {
>            future.swap(other.future);
>        }
>        shared_future(unique_future<R> && other)
>        {
>            future.swap(other.future);
>        }
> 
> How the move is made?
> 
> Is 
>            future.swap(other.future);
>            other.future.reset();
> more efficient than
>            future.reset(other.future);
>            other.future.reset();
> ? Otherwise you can change it in:
(Continue reading)

Permalink | Reply |
headers
Anthony Williams | 20 Jan 12:40

Re: Futures Review - minor implementation details

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

> Hi Anthony,
>
> Some minor implementation details:
> Why there is not other.future reset in
>         shared_future(shared_future && other)
>         {
>             future.swap(other.future);
>         }
>         shared_future(unique_future<R> && other)
>         {
>             future.swap(other.future);
>         }
>
> How the move is made?

These are the constructors. The "future" member is initially NULL, so
the swap sets "other.future" to NULL whilst transferring the value
from "other.future" to "this->future"

> Is 
>             future.swap(other.future);
>             other.future.reset();
> more efficient than
>             future.reset(other.future);
>             other.future.reset();
> ? Otherwise you can change it in:

The former avoids incrementing any reference counts. The
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 20 Jan 19:05

Re: Futures Review - minor implementation details

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, January 20, 2009 12:40 PM
Subject: Re: [boost] Futures Review - minor implementation details

> 
> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
> 
>> Hi Anthony,
>>
>> Some minor implementation details:
>> Why there is not other.future reset in
>>         shared_future(shared_future && other)
>>         {
>>             future.swap(other.future);
>>         }
>>         shared_future(unique_future<R> && other)
>>         {
>>             future.swap(other.future);
>>         }
>>
>> How the move is made?
> 
> These are the constructors. The "future" member is initially NULL, so
> the swap sets "other.future" to NULL whilst transferring the value
> from "other.future" to "this->future"

OK, I see.
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 6 Jan 23:27

Re: Futures Review - future exceptions and boost::exception

Shouldn't future exceptions inherit from boost::exception in order to work with
boost::throw_exception and be able to transfer these exception between threads?

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Steven Watanabe | 6 Jan 23:38

Re: Futures Review - future exceptions and boost::exception

AMDG

vicente.botet wrote:
> Shouldn't future exceptions inherit from boost::exception in order to work with
boost::throw_exception and be able to transfer these exception between threads?
>   

boost::throw_exception requires inheritance from std::exception, not 
boost::exception.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 7 Jan 00:27

Re: Futures Review - future exceptions and boost::exception

----- Original Message ----- 
From: "Steven Watanabe" <watanabesj <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, January 06, 2009 11:38 PM
Subject: Re: [boost] Futures Review - future exceptions and boost::exception

> 
> AMDG
> 
> vicente.botet wrote:
>> Shouldn't future exceptions inherit from boost::exception in order to work with
boost::throw_exception and be able to transfer these exception between threads?
>>   
> 
> boost::throw_exception requires inheritance from std::exception, not 
> boost::exception.

You are right. 

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Emil Dotchevski | 7 Jan 00:01

Re: Futures Review - future exceptions and boost::exception

On Tue, Jan 6, 2009 at 2:27 PM, vicente.botet <vicente.botet <at> wanadoo.fr> wrote:
> Shouldn't future exceptions inherit from boost::exception in order to work with
boost::throw_exception and be able to transfer these exception between threads?

Inheritance from boost::exception does not guarantee the ability to
use current_exception/exception_ptr, throwing using
boost::throw_exception or BOOST_THROW_EXCEPTION does
(BOOST_THROW_EXCEPTION is preferable because it'll automatically
capture the file/line location of the throw.)

--

-- 
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 6 Jan 23:31

Re: Futures Review - inheriting from futures

In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or
constructor(detail::future_impl) be protected?

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Steven Watanabe | 6 Jan 23:40

Re: Futures Review - inheriting from futures

AMDG

vicente.botet wrote:
> In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or
constructor(detail::future_impl) be protected?
>   

Why do you want to be able to inherit from futures?

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 7 Jan 00:28

Re: Futures Review - inheriting from futures

----- Original Message ----- 
From: "Steven Watanabe" <watanabesj <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, January 06, 2009 11:40 PM
Subject: Re: [boost] Futures Review - inheriting from futures

> 
> AMDG
> 
> vicente.botet wrote:
>> In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or
constructor(detail::future_impl) be protected?
>>   
> 
> Why do you want to be able to inherit from futures?

To extend their functionality.

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Steven Watanabe | 7 Jan 00:44

Re: Futures Review - inheriting from futures

AMDG

vicente.botet wrote:
>>> In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or
constructor(detail::future_impl) be protected?
>>>   
>>>       
>> Why do you want to be able to inherit from futures?
>>     
>
> To extend their functionality.
>   

I'm afraid that the above statement is absolutely zero use to me.
future is not a polymorphic class, so you don't have anything
to override.  Do you a specific use that cannot (easily) be implemented
with the current interface?

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 7 Jan 00:58

Re: Futures Review - inheriting from futures

----- Original Message ----- 
From: "Steven Watanabe" <watanabesj <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Wednesday, January 07, 2009 12:44 AM
Subject: Re: [boost] Futures Review - inheriting from futures

> 
> AMDG
> 
> vicente.botet wrote:
>>>> In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or
constructor(detail::future_impl) be protected?
>>>>   
>>>>       
>>> Why do you want to be able to inherit from futures?
>>>     
>>
>> To extend their functionality.
>>   
> 
> I'm afraid that the above statement is absolutely zero use to me.
> future is not a polymorphic class, so you don't have anything
> to override.  
We can inherit from a class that it is not polymorphic, of course we cannot use it polimorphicaly. There are a
lot of clases that inherits from non polymorphic class in Boost.
I can overrride any function in the class of course not polymorphycaly.

I can also take the future as a member

> Do you a specific use that cannot (easily) be implemented
(Continue reading)

Permalink | Reply |
headers
Steven Watanabe | 7 Jan 02:03

Re: Futures Review - inheriting from futures

AMDG

vicente.botet wrote:
>>>>> In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or
constructor(detail::future_impl) be protected?
>>>>>   
>>>>>       
>>>>>           
>>>> Why do you want to be able to inherit from futures?
>>>>     
>>>>         
>>> To extend their functionality.
>>>   
>>>       
>> I'm afraid that the above statement is absolutely zero use to me.
>> future is not a polymorphic class, so you don't have anything
>> to override.  
>>     
> We can inherit from a class that it is not polymorphic, of course we cannot use it polimorphicaly.

Of course we can.

> There are a lot of clases that inherits from non polymorphic class in Boost.
>   

Sure, but most public classes in Boost are not intended to be inherited 
from.
I still don't see the need to inherit from an ordinary value type like 
future.
(Continue reading)

Permalink | Reply |
headers
Phil Endecott | 6 Jan 23:44

Re: Futures Review Starts Today - January 5, 2009

Tom Brinkman wrote:
> Futures Review Starts Today - January 5, 2009

This is not a review.  Maybe it's a "meta-review".

One of the things that Boost tries to be is a proving-ground for things 
that are heading towards C++ standardisation.  In this case it seems to 
have gone topsy-turvy: the C++ standards committee have approved an 
implementation of futures and now Boost is reviewing two libraries 
neither of which is an exact implementation of the standard proposal.  
This doesn't seem right to me.  So:

- The idea of futures looks useful and I think Boost should have it.

- It would not be sensible to have anything other than something 
conforming to the proposed standard, except for any hacks necessary for 
pre-0x compatibility and perhaps for non-conflicting extra features.

- I believe that both of the proposals were ready for review some time 
ago.  I'm unsure of the exact chronology but I have the impression that 
if they had been reviewed by Boost more promptly then perhaps that 
review could have been available to the standards committee.

- I understand that the slowness of the review queue is a result of too 
few review managers for too many proposed libraries.  Assuming that the 
pool of review managers can't be pressed to give up more of their time, 
maybe the pool could be widened by relaxing the required 
qualifications: although reviews often require that the review manager 
does a lot of collating of opinions, I'm not aware of many cases where 
the essential accept/reject decision has been very difficult to make or
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 7 Jan 00:40

Re: Futures Review Starts Today - January 5, 2009

----- Original Message ----- 
From: "Phil Endecott" <spam_from_boost_dev <at> chezphil.org>
To: <boost <at> lists.boost.org>
Sent: Tuesday, January 06, 2009 11:44 PM
Subject: Re: [boost] Futures Review Starts Today - January 5, 2009

> One of the things that Boost tries to be is a proving-ground for things 
> that are heading towards C++ standardisation.  In this case it seems to 
> have gone topsy-turvy: the C++ standards committee have approved an 
> implementation of futures and now Boost is reviewing two libraries 
> neither of which is an exact implementation of the standard proposal.  
> This doesn't seem right to me.  So:
> 
> - The idea of futures looks useful and I think Boost should have it.

I agree completly.

> - It would not be sensible to have anything other than something 
> conforming to the proposed standard, except for any hacks necessary for 
> pre-0x compatibility and perhaps for non-conflicting extra features.

I agree again.

> - I believe that both of the proposals were ready for review some time 
> ago.  I'm unsure of the exact chronology but I have the impression that 
> if they had been reviewed by Boost more promptly then perhaps that 
> review could have been available to the standards committee.

I think this was the intention of Anthony.
(Continue reading)

Permalink | Reply |
headers
Oliver Seiler | 7 Jan 22:22
Favicon

Re: Futures Review Starts Today - January 5, 2009

Some background on myself to give context for this review:
- Long-time user of boost in commercial C++ development
- Making extensive use of threads and related constructs
- Using home-brew future-like API for managing inter-thread communciations

> What is your evaluation of the design(s)?

As others have noted, futures now appear in the draft C++ standard,
and Anthony's API conforms closely to that (or, more correctly, the
draft C++ standard appears to be based on Anthony's API). Unless I
have some reason to think the draft C++ standard will completely
change the proposed future API, I would tend to support Anthony's API.
As Anthony has said in this thread, if conformance to the draft C++
standard future API is required for inclusion, he would help with that
effort, for either API, which is fine with me.

Design-wise, I prefer Anthony's API as it seems simpler to use;
Braddock's API includes things of questionable value (to me).
Specifically:
- callbacks seem tricky to use/implement safely
- future streams seem unnecessary at this point

Braddock's API does try to address the notion of scheduling. One of
the problems I've run into in using threads in C++ is that it is very
important to treat threads as resources to be managed just like other
limited OS resources. It generally isn't enough to say "oh, we'll just
execute this on another thread"; this can often lead to a situation
where you run out of threads, especially when thread execution can
block. Scheduling, deciding when a thread can run (because futures
that the execution is dependent on have become available), is a tricky
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 10 Jan 15:15

Re: Futures Review - typeof registering

Hi,

My use case is a function that request an asynchronous executor to fork all the functions given as parameter
and returns a quite complex type

    template< typename AE, typename F1, ..., typename Fn> 
    typename result_of::fork_all<AE, fusion::tuple<F1,..., Fn> >::type
    fork_all( AE& ae, F1 f1, ..., Fn fn );

and used as follows:

    bith::launcher ae;
    typedef bith::result_of::fork_all<bith::launcher ,boost::fusion::tuple<int(*)(),int(*)()>
>::type auto_type;
    auto_type handles= bith::fork_all(ae, simple_thread, simple_thread);

For a launcher asynchronous executor, 
    result_of::fork_all<AE, fusion::tuple<F1,..., Fn> >::type 
is a 
    boost::fusion::tuple<unique_future<result_of<Fk() ...>.

If we register unique_future on the Boost.Typeof library, we are able to write

    BOOST_AUTO(handles, bith::fork_all(ae, simple_thread, simple_thread));

which is much simpler.

Next follows the contents of the file. Could this file be added to the Boost.Future librarie?

Thanks,
(Continue reading)

Permalink | Reply |
headers
Anthony Williams | 20 Jan 15:39

Re: Futures Review - typeof registering

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

> If we register unique_future on the Boost.Typeof library, we are
> able to write
>
>     BOOST_AUTO(handles, bith::fork_all(ae, simple_thread, simple_thread));
>
> which is much simpler.
>
> Next follows the contents of the file. Could this file be added to
> the Boost.Future librarie?

I'd have thought so. I'm not keen on depending on boost.typeof, but it
would be fine as a separate header.

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
Permalink | Reply |
headers
vicente.botet | 20 Jan 19:44

Re: Futures Review - typeof registering

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, January 20, 2009 3:39 PM
Subject: Re: [boost] Futures Review - typeof registering

> 
> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
> 
>> If we register unique_future on the Boost.Typeof library, we are
>> able to write
>>
>>     BOOST_AUTO(handles, bith::fork_all(ae, simple_thread, simple_thread));
>>
>> which is much simpler.
>>
>> Next follows the contents of the file. Could this file be added to
>> the Boost.Future librarie?
> 
> I'd have thought so. I'm not keen on depending on boost.typeof, but it
> would be fine as a separate header.

Great,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Vicente Botet Escriba | 14 Jan 15:31

Re: Futures Review - wait_for_any Concept parameters


Hi Anthony,

Please, could you give us which is the Concept for the wait_for_any
parameter template function? It is not clear from the documentation which
are the functions must be provided by the Models.

Thanks,
Vicente
--

-- 
View this message in context: http://www.nabble.com/Futures-Review-Starts-Today---January-5%2C-2009-tp21303049p21457085.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Anthony Williams | 14 Jan 15:43

Re: Futures Review - wait_for_any Concept parameters

Vicente Botet Escriba <vicente.botet <at> wanadoo.fr> writes:

> Please, could you give us which is the Concept for the wait_for_any
> parameter template function? It is not clear from the documentation which
> are the functions must be provided by the Models.

With the library as it stands, wait_for_any works with any
specializations of unique_future or shared_future, but only those ---
it is inherently tied to their implementation.

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
Permalink | Reply |
headers
vicente.botet | 18 Jan 10:46

Re: Futures Review - wait_for_any Concept parameters

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Wednesday, January 14, 2009 3:43 PM
Subject: Re: [boost] Futures Review - wait_for_any Concept parameters

> 
> Vicente Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
> 
>> Please, could you give us which is the Concept for the wait_for_any
>> parameter template function? It is not clear from the documentation which
>> are the functions must be provided by the Models.
> 
> With the library as it stands, wait_for_any works with any
> specializations of unique_future or shared_future, but only those ---
> it is inherently tied to their implementation.

Oh, I see. I've missed that on the documentation which is clearly stated on the preconditions.

If this function works only for unique/shared future, its name is too generic to be placed at the boost
namespace. Do you plan to include it in a specific futures namespace?

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Anthony Williams | 20 Jan 15:07

Re: Futures Review - wait_for_any Concept parameters

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

> ----- Original Message ----- 
> From: "Anthony Williams" <anthony.ajw <at> gmail.com>
> To: <boost <at> lists.boost.org>
> Sent: Wednesday, January 14, 2009 3:43 PM
> Subject: Re: [boost] Futures Review - wait_for_any Concept parameters
>
>
>> 
>> Vicente Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
>> 
>>> Please, could you give us which is the Concept for the wait_for_any
>>> parameter template function? It is not clear from the documentation which
>>> are the functions must be provided by the Models.
>> 
>> With the library as it stands, wait_for_any works with any
>> specializations of unique_future or shared_future, but only those ---
>> it is inherently tied to their implementation.
>
> Oh, I see. I've missed that on the documentation which is clearly
> stated on the preconditions.
>
> If this function works only for unique/shared future, its name is
> too generic to be placed at the boost namespace. Do you plan to
> include it in a specific futures namespace?

It could be moved inside a namespace. I'm not really
bothered. Alternatively, if it could be extended for other types then
that would work too.
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 15 Jan 18:47

Re: Futures - wait callback with a user specific parameter.

Hi,

Currently the wait callback parameter is either a promise or packaged_task 
        template<typename F>
        void set_wait_callback(F f);

prom.set_wait_callback(f); // will call f(&prom)
task.set_wait_callback(f); // will call f(&task)

I would like to have a wait callback with a user specific parameter. 
            template<typename F,typename U>
            void set_wait_callback(F f,U* u);  // will call f(u)

prom.set_wait_callback(f, x); // will call f(x)

The use case is a class that contains a promise and wants to provide a set_wait_callback. Which parameter
will have the wait calback? A promise. But the user is not aware that my class has promise, and he will surely
want to have as parameter a pointer to my class. So the simpler is to provide a user specific parameter that
is defaulted to instance providing the wait_callback setting.

Of course my class can wrap the user function and the class instance

template <typename R>
class X {
        template <typename F>
        static void wait_callback_wrapper(promise<R>* p, F f, X*x) {
            f(x);
        }

        template<typename F>
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 15 Jan 21:29

Re: Futures - wait callback with a user specific parameter.

----- Original Message ----- 
From: "vicente.botet" <vicente.botet <at> wanadoo.fr>
To: <boost <at> lists.boost.org>
Sent: Thursday, January 15, 2009 6:47 PM
Subject: Re: [boost] Futures - wait callback with a user specific parameter.

> 
> Hi,
> 
> Currently the wait callback parameter is either a promise or packaged_task 
>        template<typename F>
>        void set_wait_callback(F f);
> 
> prom.set_wait_callback(f); // will call f(&prom)
> task.set_wait_callback(f); // will call f(&task)
> 
> I would like to have a wait callback with a user specific parameter. 
>            template<typename F,typename U>
>            void set_wait_callback(F f,U* u);  // will call f(u)
> 
> prom.set_wait_callback(f, x); // will call f(x)
> 
> The use case is a class that contains a promise and wants to provide a set_wait_callback. Which parameter
will have the wait calback? A promise. But the user is not aware that my class has promise, and he will surely
want to have as parameter a pointer to my class. So the simpler is to provide a user specific parameter that
is defaulted to instance providing the wait_callback setting.
> 
> Of course my class can wrap the user function and the class instance
> 
> template <typename R>
(Continue reading)

Permalink | Reply |
headers
Anthony Williams | 20 Jan 15:06

Re: Futures - wait callback with a user specific parameter.

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

> From: "vicente.botet" <vicente.botet <at> wanadoo.fr>

>> Currently the wait callback parameter is either a promise or packaged_task 
>>        template<typename F>
>>        void set_wait_callback(F f);
>> 
>> prom.set_wait_callback(f); // will call f(&prom)
>> task.set_wait_callback(f); // will call f(&task)
>> 
>> I would like to have a wait callback with a user specific parameter. 
>>            template<typename F,typename U>
>>            void set_wait_callback(F f,U* u);  // will call f(u)
>> 
>> prom.set_wait_callback(f, x); // will call f(x)
>> 
>> The use case is a class that contains a promise and wants to
>> provide a set_wait_callback. Which parameter will have the wait
>> calback? A promise. But the user is not aware that my class has
>> promise, and he will surely want to have as parameter a pointer to
>> my class. So the simpler is to provide a user specific parameter
>> that is defaulted to instance providing the wait_callback setting.
>> 
>> Of course my class can wrap the user function and the class instance
>> 
>> template <typename R>
>> class X {
>>        template <typename F>
>>        static void wait_callback_wrapper(promise<R>* p, F f, X*x) {
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 15 Jan 19:25

Re: Futures Review - one or many callbacks

Hi,

The one or many callbacks setting subject comeback regularly. I would like the Boost.Future future
library supports callbacks but not always, i.e. I would like a design that has 0-callbacks (current
standard recomendation). On top of it we must be able to implement 1-callbacks, and on top of it implement
n-callbacks (or signals). This should be applied either to callbacks on wait (Anthony) as callback on
setting (Braddock). 

Is it possible to achieve this design? If this is not possible IMHO the standard C++0x futures is
incomplete, and should be modified. If it is possible, is there any deep reason to not provide it?

Thanks,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 16 Jan 08:40

Re: Futures Review - wait_for_any complexity

Hi,

there was a long discusion about the complexity of wait_for_any some mounts ago. If I understood well the
probleme was in the future_waiter::wait

            unsigned wait()
            {
                all_futures_lock lk(futures);
                for(;;)
                {
                    for(unsigned i=0;i<futures.size();++i)  // O(N)
                    {
                        if(futures[i].future->done)
                        {
                            return futures[i].index;
                        }
                    }
                    cv.wait(lk);
                }
            }

What we need is a synchonization structure that returns a user specific data (in this case the index). So we
can replace by

            unsigned wait()
            {
                all_futures_lock lk(futures);
                return cv_with_value.wait(lk);
            }
(Continue reading)

Permalink | Reply |
headers
Anthony Williams | 20 Jan 15:01

Re: Futures Review - wait_for_any complexity

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

> there was a long discusion about the complexity of wait_for_any some
> mounts ago. If I understood well the probleme was in the
> future_waiter::wait
>
>     unsigned wait()
>     {
>         all_futures_lock lk(futures);
>         for(;;)
>         {
>             for(unsigned i=0;i<futures.size();++i)  // O(N)
>             {
>                 if(futures[i].future->done)
>                 {
>                     return futures[i].index;
>                 }
>             }
>             cv.wait(lk);
>         }
>     }

Yes.

> What we need is a synchonization structure that returns a user
> specific data (in this case the index). So we can replace by
>
>     unsigned wait()
>     {
>         all_futures_lock lk(futures);
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 20 Jan 19:12

Re: Futures Review - wait_for_any complexity


----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, January 20, 2009 3:01 PM
Subject: Re: [boost] Futures Review - wait_for_any complexity

> 
> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
> 

>> What we need is a synchonization structure that returns a user
>> specific data (in this case the index). So we can replace by
>>
>>     unsigned wait()
>>     {
>>         all_futures_lock lk(futures);
>>         return cv_with_value.wait(lk);
>>     }
> 
> I'm not sure. I think we're better off with a simple
> mutex/value/cond-var triplet in the waiter. We then don't need the
> "all_futures_lock".
> 
>    unsigned wait()
>    {
>        boost::unique_lock<boost::mutex> lk(mut);
>        while(ready_future_index<0)
>        {
>            cv.wait(lk);
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 16 Jan 18:48

Re: Futures Review - Allowing partial specialization of wait_for_any

Hi,

The functions wait_for_all and wait_for_any seams quite generic and could be applied to other
asynchronous completion tokens (ACT), as for example the tp::task from Boost.ThreadPool. 

In order to do that we need to be able to partialy specialize these functions or use traits:

Let me start with a partial specialization proposal 

    template<typename F1,typename F2,typename F3>
    unsigned wait_for_any(F1& f1,F2& f2,F3& f3)
    {
        return partial_specialization_workaround::wait_for_any::apply(f1,f2, f3);
    }

    namespace partial_specialization_workaround {
        template<typename Types>
        struct wait_for_any;
        template<typename F1,typename F2,typename F3>
        struct wait_for_any<vector3<F1,F2,F3> > {
            unsigned apply(F1& f1,F2& f2,F3& f3) {
                detail::future_waiter waiter;
                waiter.add(f1);
                waiter.add(f2);
                waiter.add(f3);
                return waiter.wait();
            }
        };
    }
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 17 Jan 15:44

Re: Futures Review - wait_for_ on fusion sequences

Hi,

Could the wait_for_ functions be overloaded for fusion sequences, e.g.

fusion::vector<shared_future<int>, shared_future<string> > seq;

unsigned i = wait_for_any(seq);

I have checkd the followig code and it works for me.

struct waiter_add {
    waiter_add(boost::detail::future_waiter& waiter) : waiter_(waiter) {}
    boost::detail::future_waiter& waiter_;
    template<typename ACT>
    void operator()(ACT& act) const {
        waiter_.add(act);
    }
};
template<typename FusionSequence>
unsigned wait_for_any(FusionSequence& seq)  {
    boost::detail::future_waiter waiter;
    boost::fusion::for_each(seq, waiter_add(waiter));
    return waiter.wait();
}

Thanks,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 18 Jan 21:52

Re: Futures Review - fork_after

Hi,

I have add the fork_after function to Boost.InterThreads. The prototype allows to execute
asynchronously N functions and execute asynchronously a function that depends on the completion of N functions.

    bith::shared_launcher ae;
    BOOST_AUTO(actT, bith::fork_all(ae, fct1, fct2));
    BOOST_AUTO(act,bith::fork_after(ae, fct3, actT));
    act.wait();

bith::shared_launcher is an asynchronous executor (AE) that executes asynchronously a function on a new thread.

bith::fork_all request the AE to execute asynchronously each function. It returns a fusion tuple of the
asynchronous completion token (ACT) associated the the ae.

bith::fork_after request the AE to execute a function asynchronously once each one of ACTs in the
dependency tuple parameter are ready. It is similar to the async_with_dependencies proposed Peter Dimov.

I have used for that Boost.Future (Anthony proposal).

Is there any interest in this kind of feautres?

Best,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
vicente.botet | 18 Jan 22:12

Re: Futures Review - Has the review been canceled?

Hi,

what is happening with the Boost.Future review. The authors do not respond too much to the posts. There iare
not too much reviews neither posts. 
There was a review sent the 6th  - no comments. Another the 7th,the same
I have posted 6 post for discusion and no answerr since the 15th.

We are amready the 18th, the review finish the 20h and Tom, the review manager is not calling for reviews,
neither pesting on the authors to answer the questions included in the posts.

We don't have any sign of Braddock since a lot time, is he hill?

Am I missing something? Has the review been canceled? 

Tom please could you clarify these questions?

Thanks,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Anthony Williams | 20 Jan 15:03

Re: Futures Review - Has the review been canceled?

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

> what is happening with the Boost.Future review. The authors do not
> respond too much to the posts. There iare not too much reviews
> neither posts.  There was a review sent the 6th - no
> comments. Another the 7th,the same I have posted 6 post for
> discusion and no answerr since the 15th.

Sorry for the lack of response; I've not been reading the boost list
for a few days.

> Am I missing something? Has the review been canceled? 

Not to my knowledge.

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
Permalink | Reply |
headers
vicente.botet | 18 Jan 23:56

Re: Futures Review Starts Today - January 5, 2009

Hi, here is my review. 

* What is your evaluation of the design?

Both libraries have a good design. The fact that the porposal of Anthony is closer to the C++0x proposal let
me think that we should base the Boost.Library on it and see how to add the other features.

For the exception propagation mechanism both libraries must use Boost.Exception (as is already the case
of Anthony version).

The library should use the forthcomming Boost.Move library to emulate the move semantics.
The library should use the forthcomming Boost.Chrono library for time and duration.

With wait_for_all and wait_for_any we don't need the Braddock completion callback setting, even if it
could be less efficient, it is safer.

I have however, some points that seems to me necessary for acceptance:

++ C++0x adaptations:
    ++ adapt the exceptions hierarchy to a single exception.
    ++ Change the names of timed_wait to follow the  stndard wait_until and wait_for.
+ Add a typeof registerig (See http://www.nabble.com/forum/ViewPost.jtp?post=21388525&framed=y)

++ Allows partial specialization of wait_for_any (see
http://www.nabble.com/forum/ViewPost.jtp?post=21504868&framed=y) 

+ Use a get_future traits on the default implementation of wait_for_any and wait_for_all

++ Futures are asynchronous completion tokens. I would like the library defines this concept. Functions
like wait_for_any, wait_for_all should work with every model of an ACT. If the implementation could not
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 24 Jan 00:38

Re: Futures Review - can move_dest_type be public?

Hi,

The function get is defined in the documentation with following prototypes

    R&& unique_future::get();
    R& unique_future<R&>::get();
    void unique_future<void>::get();

But when the move semantic is emulated this is just translated as 

        move_dest_type get()

with move_dest_type defined depending on the future template parameter as follows

        typedef typename detail::future_traits<R>::move_dest_type move_dest_type;

        template<typename T>
        struct future_traits
        {
#ifdef BOOST_HAS_RVALUE_REFS
            typedef T const& source_reference_type;
            struct dummy;
            typedef typename boost::mpl::if_<boost::is_fundamental<T>,dummy&,T&&>::type rvalue_source_type;
            typedef typename boost::mpl::if_<boost::is_fundamental<T>,T,T&&>::type move_dest_type;
#else
            typedef T& source_reference_type;
            typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T>
>,boost::detail::thread_move_t<T>,T const&>::type rvalue_source_type;
            typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T>
>,boost::detail::thread_move_t<T>,T>::type move_dest_type;
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 10 Feb 17:58

Re: [repost] Futures Review - can move_dest_type be public?

Hello, I first posted this two weeks ago for the review, allow me to repost just in
case it went unnoticed:

----- Original Message ----- 
From: "vicente.botet" <vicente.botet <at> wanadoo.fr>
To: <boost <at> lists.boost.org>
Sent: Saturday, January 24, 2009 12:38 AM
Subject: Re: [boost] Futures Review - can move_dest_type be public?

> 
> Hi,
> 
> The function get is defined in the documentation with following prototypes
> 
>    R&& unique_future::get();
>    R& unique_future<R&>::get();
>    void unique_future<void>::get();
> 
> But when the move semantic is emulated this is just translated as 
> 
>        move_dest_type get()
> 
> with move_dest_type defined depending on the future template parameter as follows
> 
>        typedef typename detail::future_traits<R>::move_dest_type move_dest_type;
> 
>        template<typename T>
>        struct future_traits
>        {
> #ifdef BOOST_HAS_RVALUE_REFS
(Continue reading)

Permalink | Reply |
headers
Anthony Williams | 10 Feb 18:22

Re: [repost] Futures Review - can move_dest_type be public?

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

>> Hi,
>> 
>> The function get is defined in the documentation with following prototypes
>> 
>>    R&& unique_future::get();
>>    R& unique_future<R&>::get();
>>    void unique_future<void>::get();
>> 
>> But when the move semantic is emulated this is just translated as 
>> 
>>        move_dest_type get()
>> 
>> with move_dest_type defined depending on the future template parameter as follows
>> 
>>        typedef typename detail::future_traits<R>::move_dest_type move_dest_type;
>> 
>>        template<typename T>
>>        struct future_traits
>>        {
>> #ifdef BOOST_HAS_RVALUE_REFS
>>            typedef T const& source_reference_type;
>>            struct dummy;
>>            typedef typename boost::mpl::if_<boost::is_fundamental<T>,dummy&,T&&>::type rvalue_source_type;
>>            typedef typename boost::mpl::if_<boost::is_fundamental<T>,T,T&&>::type move_dest_type;
>> #else
>>            typedef T& source_reference_type;
>>            typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T>
>,boost::detail::thread_move_t<T>,T const&>::type rvalue_source_type;
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 10 Feb 18:38

Re: [repost] Futures Review - can move_dest_type be public?

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, February 10, 2009 6:22 PM
Subject: Re: [boost] [repost] Futures Review - can move_dest_type be public?

> 
> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
> 
>>> Hi,
>>> 
>>> The function get is defined in the documentation with following prototypes
>>> 
>>>    R&& unique_future::get();
>>>    R& unique_future<R&>::get();
>>>    void unique_future<void>::get();
>>> 
>>> But when the move semantic is emulated this is just translated as 
>>> 
>>>        move_dest_type get()
>>> 
>>> with move_dest_type defined depending on the future template parameter as follows
>>> 
>>>        typedef typename detail::future_traits<R>::move_dest_type move_dest_type;
>>> 
>>>        template<typename T>
>>>        struct future_traits
>>>        {
>>> #ifdef BOOST_HAS_RVALUE_REFS
>>>            typedef T const& source_reference_type;
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 24 Jan 01:14

Re: Futures Review - ??? shared_future<T>::get()

Hi,

In C++0x

    const R& shared_future::get() const;
    R& shared_future<R&>::get() const;
    void shared_future<void>::get() const;

In the documentation We found in the synopsis class
    R get(); 

in the Member function get() 
    const R& get(); 

in the description

Effects:If *this is associated with an asynchronous result, waits until the result is ready as-if by a call
to jss::shared_future<R>::wait(), and returns a const reference to the result. 
Returns:If the result type R is a reference, returns the stored reference. If R is void, there is no return
value. Otherwise, returns a const reference to the value stored in the asynchronous result. 

In the code we have 
        R get()

There is a lot of incoherences. Which is the correct one?

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 26 Jan 23:00

Re: Futures Review - Should packaged_task be CopyConstructible?

Hi,

Currently when we set_wait_callback on a packaged_task, the packaged_task is given by reference to the
callback function. This means that the packaged_task can not be moved.

As packaged_task is not CopyConstructible this limits quite a lot its use together with
set_wait_callback. We need to pass it always by reference as functions parameters and can't be returned
by a function.

I have tried to make a lazy_call function similar to spawn_task in the defined in N2709

template<typename F>
std::unique_future<typename std::result_of<F()>::type> spawn_task(F f)
{
    typedef typename std::result_of<F()>::type result_type;
    std::packaged_task<result_type()> task(std::move(f));
    std::unique_future<result_type> res(task.get_future());
    std::thread(std::move(task));
    return res;
}

Here it is 

template<typename F>
std::unique_future<typename std::result_of<F()>::type> lazy_call(F f)
{
    typedef typename std::result_of<F()>::type result_type;
    std::packaged_task<result_type> task(std::move(f));
    task.set_wait_callback(invoke_lazy_task<result_type>())
    std::unique_future<result_type> res(task.get_future());
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 10 Feb 18:00

Re: Futures Review - Should packaged_task beCopyConstructible?

Hello, I first posted this two weeks ago, allow me to repost just in
case it went unnoticed:

Best,
Vicente
----- Original Message ----- 
From: "vicente.botet" <vicente.botet <at> wanadoo.fr>
To: <boost <at> lists.boost.org>
Sent: Monday, January 26, 2009 11:00 PM
Subject: Re: [boost] Futures Review - Should packaged_task beCopyConstructible?

> 
> Hi,
> 
> Currently when we set_wait_callback on a packaged_task, the packaged_task is given by reference to the
callback function. This means that the packaged_task can not be moved.
> 
> As packaged_task is not CopyConstructible this limits quite a lot its use together with
set_wait_callback. We need to pass it always by reference as functions parameters and can't be returned
by a function.
> 
> I have tried to make a lazy_call function similar to spawn_task in the defined in N2709
> 
> template<typename F>
> std::unique_future<typename std::result_of<F()>::type> spawn_task(F f)
> {
>    typedef typename std::result_of<F()>::type result_type;
>    std::packaged_task<result_type()> task(std::move(f));
>    std::unique_future<result_type> res(task.get_future());
>    std::thread(std::move(task));
(Continue reading)

Permalink | Reply |
headers
Anthony Williams | 10 Feb 18:28

Re: Futures Review - Should packaged_task beCopyConstructible?

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

>> 
>> Currently when we set_wait_callback on a packaged_task, the
>> packaged_task is given by reference to the callback function. This
>> means that the packaged_task can not be moved.
>> 
>> As packaged_task is not CopyConstructible this limits quite a lot its
>> use together with set_wait_callback. We need to pass it always by
>> reference as functions parameters and can't be returned by a
>> function.
>> 
>> I have tried to make a lazy_call function similar to spawn_task in
>> the defined in N2709
>> 
>> template<typename F>
>> std::unique_future<typename std::result_of<F()>::type> spawn_task(F f)
>> {
>>    typedef typename std::result_of<F()>::type result_type;
>>    std::packaged_task<result_type()> task(std::move(f));
>>    std::unique_future<result_type> res(task.get_future());
>>    std::thread(std::move(task));
>>    return res;
>> }
>> 
>> Here it is 
>> 
>> template<typename F>
>> std::unique_future<typename std::result_of<F()>::type> lazy_call(F f)
>> {
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 10 Feb 18:47

Re: Futures Review - Should packaged_taskbeCopyConstructible?

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, February 10, 2009 6:28 PM
Subject: Re: [boost] Futures Review - Should packaged_taskbeCopyConstructible?

> 
> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
> 
>> So I've
>>> tried to move the packaged_task which don't work either because the
>>> promise is broken
>>> 
>>> template<typename F>
>>> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f)
>>> {
>>>    typedef typename std::result_of<F()>::type result_type;
>>>    std::packaged_task<result_type> task(std::move(f));
>>>    task.set_wait_callback(invoke_lazy_task<result_type>())
>>>    return task;
>>> }
> 
> Why does this not work? Is it that the callback is broken (it gets
> passed the wrong task?) If so, that's the part that needs fixing, rather
> than the copyability of packaged_task.

Sorry i was not clear. The problem is that the reference to the task 

   std::packaged_task<result_type> task(std::move(f));
(Continue reading)

Permalink | Reply |
headers
Anthony Williams | 11 Feb 09:31

Re: Futures Review - Should packaged_taskbeCopyConstructible?

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

> Sorry i was not clear. The problem is that the reference to the task 
>
>    std::packaged_task<result_type> task(std::move(f));
>
> has been stored in the set_wait_callback. But this address is no more
> valable when the function returns, so when the user gets the future
> and call to get, the callback uses a bad address. Hoping it is clear
> now.

Yes, it's clear. That's a design issue with set_wait_callback.

> Ok, I see. Anyway, I think that examples like 
>  template<typename F>
> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f);
>
> should be included in the library, at least as an example.

That's a good idea.

Anthony
--

-- 
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Just Software Solutions Ltd         | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 11 Feb 10:44

Re: Futures Review - Shouldpackaged_taskbeCopyConstructible?

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Wednesday, February 11, 2009 9:31 AM
Subject: Re: [boost] Futures Review - Shouldpackaged_taskbeCopyConstructible?

> 
> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
> 
>> Sorry i was not clear. The problem is that the reference to the task 
>>
>>    std::packaged_task<result_type> task(std::move(f));
>>
>> has been stored in the set_wait_callback. But this address is no more
>> valable when the function returns, so when the user gets the future
>> and call to get, the callback uses a bad address. Hoping it is clear
>> now.
> 
> Yes, it's clear. That's a design issue with set_wait_callback.
> 
>> Ok, I see. Anyway, I think that examples like 
>>  template<typename F>
>> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f);
>>
>> should be included in the library, at least as an example.
> 
> That's a good idea.

Have you an idea how to solve the design issue to implement lazy_call?
In http://www.nabble.com/Futures-Review-Starts-Today---January-5%2C-2009-tt21303049.html, I
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 26 Jan 23:30

Re: Futures Review Starts Today - January 5, 2009

Hi,

are lazy futures a kind of function pointer? How is the example from the documentation 

    int calculate_the_answer_to_life_the_universe_and_everything(){
        return 42;
    }

    void invoke_lazy_task(jss::packaged_task<int>& task){
        try    {
            task();
        }    catch(jss::task_already_started&)    {}
    }

    int main() {
        jss::packaged_task<int> task(calculate_the_answer_to_life_the_universe_and_everything);
        task.set_wait_callback(invoke_lazy_task);
        jss::unique_future<int> f(task.get_future());
        assert(f.get()==42);
    }

differ from 

    int main(){
        function<int()> task(calculate_the_answer_to_life_the_universe_and_everything);
        assert(task()==42);
    }

What I'm missing?
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 10 Feb 17:00

Re: Futures Review -- Where we are with the Futures review?

Hi,
----- Original Message ----- 
From: "Tom Brinkman" <reportbase <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, January 06, 2009 2:25 AM
Subject: [boost] Futures Review Starts Today - January 5, 2009

> 
> Futures Review Starts Today - January 5, 2009
> 

Where we are with the Futures review?
There was not too much reviews, neither responses from the authors, ... What happened?
Nevertheless, I'm sure that this library is essential to the construction of high level concurrent libraries.
Tom, it will be good if you can close this extraneous review.

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Anthony Williams | 10 Feb 17:58

Re: Futures Review -- Where we are with the Futures review?

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

>> 
>> Futures Review Starts Today - January 5, 2009
>> 
>
> Where we are with the Futures review?

Good question. It was supposed to be over by now, but there's been no
statement from Tom.

> There was not too much reviews, neither responses from the authors,
> ... What happened?

Sorry for not taking the time to respond to all your comments. They are
much appreciated. Maybe the lack of reviews indicates a lack of interest
from the Boost community? That's a shame, if so.

> Nevertheless, I'm sure that this library is essential to the
> construction of high level concurrent libraries.

If you want to include my code (or something derived from it) in your
interthreads library, or Oliver wants to include it with his threadpool
submission, that's fine by me.

Anthony
--

-- 
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Just Software Solutions Ltd         | http://www.justsoftwaresolutions.co.uk
(Continue reading)

Permalink | Reply |
headers
David Abrahams | 10 Feb 18:08
Favicon
Gravatar

Re: Futures Review -- Where we are with the Futures review?


on Tue Feb 10 2009, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:

> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
>
>>> 
>>> Futures Review Starts Today - January 5, 2009
>>> 
>>
>> Where we are with the Futures review?
>
> Good question. It was supposed to be over by now, but there's been no
> statement from Tom.
>
>> There was not too much reviews, neither responses from the authors,
>> ... What happened?
>
> Sorry for not taking the time to respond to all your comments. They are
> much appreciated. Maybe the lack of reviews indicates a lack of interest
> from the Boost community? That's a shame, if so.

>From my point of view, I was interested, but I found the idea of
reviewing two libraries at once to be simply overwhelming.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Anthony Williams | 10 Feb 18:32

Re: Futures Review -- Where we are with the Futures review?

David Abrahams <dave <at> boostpro.com> writes:

> on Tue Feb 10 2009, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
>
>> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
>>
>>>> 
>>>> Futures Review Starts Today - January 5, 2009
>>>> 
>>>
>>> Where we are with the Futures review?

>> Maybe the lack of reviews indicates a lack of interest
>> from the Boost community? That's a shame, if so.
>
>>From my point of view, I was interested, but I found the idea of
> reviewing two libraries at once to be simply overwhelming.

Given that we do have two proposed libraries, have you any suggestions
on how to make the review process less overwhelming?

Anthony
--

-- 
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Just Software Solutions Ltd         | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply |
headers
Christopher Jefferson | 10 Feb 18:51
Favicon

Re: Futures Review -- Where we are with the Futures review?


On 10 Feb 2009, at 17:08, David Abrahams wrote:

>
> on Tue Feb 10 2009, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
>
>> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
>>
>>>>
>>>> Futures Review Starts Today - January 5, 2009
>>>>
>>>
>>> Where we are with the Futures review?
>>
>> Good question. It was supposed to be over by now, but there's been no
>> statement from Tom.
>>
>>> There was not too much reviews, neither responses from the authors,
>>> ... What happened?
>>
>> Sorry for not taking the time to respond to all your comments. They  
>> are
>> much appreciated. Maybe the lack of reviews indicates a lack of  
>> interest
>> from the Boost community? That's a shame, if so.
>
>> From my point of view, I was interested, but I found the idea of
> reviewing two libraries at once to be simply overwhelming.

I want to back this up - I am very interested in futures, but I
(Continue reading)

Permalink | Reply |
headers
Giovanni Piero Deretta | 10 Feb 19:11

Re: Futures Review -- Where we are with the Futures review?

On Tue, Feb 10, 2009 at 6:51 PM, Christopher Jefferson
<chris <at> bubblescope.net> wrote:
> On 10 Feb 2009, at 17:08, David Abrahams wrote:
>> on Tue Feb 10 2009, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
>>>
>>> Sorry for not taking the time to respond to all your comments. They are
>>> much appreciated. Maybe the lack of reviews indicates a lack of interest
>>> from the Boost community? That's a shame, if so.
>>
>> From my point of view, I was interested, but I found the idea of
>> reviewing two libraries at once to be simply overwhelming.
>
> I want to back this up - I am very interested in futures, but I decided not
> to get involved in this review for two reasons.
>
> 1) Medium to long term, I want to be able to use, or build on, the standard
> futures, so I would like a library which strictly extends that.
> 2) I don't feel sufficently qualified to choose between two different
> libraries, and all the trade-offs involved, knowing (assuming?) that at
> least one of the libraries would have to be rejected.
>

Seconded. I'm quite interested in a futures library, but I didn't have
the time nor the the ability to try to find out which library really
were the be selected.

> I would be much happier if the two library authors could come together and
> merge their work.

Yes please :)
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 10 Feb 19:40

Re: Futures Review -- Where we are with the Futures review?

----- Original Message ----- 
From: "Christopher Jefferson" <chris <at> bubblescope.net>
To: <boost <at> lists.boost.org>
Sent: Tuesday, February 10, 2009 6:51 PM
Subject: Re: [boost] Futures Review -- Where we are with the Futures review?

> 
> 
> On 10 Feb 2009, at 17:08, David Abrahams wrote:
> 
>>
>> on Tue Feb 10 2009, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
>>
>>> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
>>>
>>>>>
>>>>> Futures Review Starts Today - January 5, 2009
>>>>>
>>>>
>>>> Where we are with the Futures review?
>>>
>>> Good question. It was supposed to be over by now, but there's been no
>>> statement from Tom.
>>>
>>>> There was not too much reviews, neither responses from the authors,
>>>> ... What happened?
>>>
>>> Sorry for not taking the time to respond to all your comments. They  
>>> are
>>> much appreciated. Maybe the lack of reviews indicates a lack of
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 10 Feb 18:13

Re: Futures Review -- Where we are with the Futures review?

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw <at> gmail.com>
To: <boost <at> lists.boost.org>
Sent: Tuesday, February 10, 2009 5:58 PM
Subject: Re: [boost] Futures Review -- Where we are with the Futures review?

> 
> "vicente.botet" <vicente.botet <at> wanadoo.fr> writes:
> 
>>> 
>>> Futures Review Starts Today - January 5, 2009
>>> 
>>
>> Where we are with the Futures review?
> 
> Good question. It was supposed to be over by now, but there's been no
> statement from Tom.
> 
>> There was not too much reviews, neither responses from the authors,
>> ... What happened?
> 
> Sorry for not taking the time to respond to all your comments. They are
> much appreciated. Maybe the lack of reviews indicates a lack of interest
> from the Boost community? That's a shame, if so.

Could you try to respond now. I'll realy appreciate. 

>> Nevertheless, I'm sure that this library is essential to the
>> construction of high level concurrent libraries.
>
(Continue reading)

Permalink | Reply |

Gmane