Re: [boost] Re: A new boost::thread implementation?

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-12 12:16:11

David Abrahams said:
> "William E. Kempf" <wekempf_at_[hidden]> writes:
>
>>> From: David Abrahams <dave_at_[hidden]>
>>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>> > It's a tool that allows high-level interfaces to be built. Whether
>>> people will want/need to build their own high-level interfaces is
>>> another story.
>>>
>>> I think it's a valuable question to ask whether /everyone/ will want
>>> to create /the same/ high-level interface ;-).  In other words, as
>>> long as we have a bunch of low-level thread primitives, I prefer to
>>> reduce interface complexity and increase encapsulation unless we can
>>> find a specific use for a medium-level interface.
>>
>> How about this compromise:
>
> <snip>
>
> I don't want either of these to have a separate function (operator() in
> this case) which initiates the call, for reasons described earlier
>
> My suggestion:
>
>   template <typename R>
>   class future
>   {
>   public:
>       template <class F, class Executor>
>       future(F const& f, Executor const& e)
>           : m_pimpl(new async_call<R>(f))
>       {
>           (*get())();
>       }
>
>       future(const future<R>& other)
>       {
>           mutex::scoped_lock lock(m_mutex);
>           m_pimpl = other.m_pimpl;
>       }
>
>       future<R>& operator=(const future<R>& other)
>       {
>           mutex::scoped_lock lock(m_mutex);
>           m_pimpl = other.m_pimpl;
>       }
>
>       R result() const
>       {
>           return get()->result();
>       }
>
>   private:
>       shared_ptr<async_call<R> > get() const
>       {
>           mutex::scoped_lock lock(m_mutex);
>           return m_pimpl;
>       }
>
>       shared_ptr<async_call<R> > m_pimpl;
>       mutable mutex m_mutex;
>   };
>
>   // Not convinced that this helps, but...
>   template <class R>
>   R result(future<R> const& f)
>   {
>       return f.result();
>   }
>
> ...and I don't care whether async_call gets implemented as part of the
> public interface or not, but only because I can't see a compelling
> reason to have it yet.

OK.  Thanks for the input.  I go from here.

-- 
William E. Kempf