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

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-10 16:42:05

"Peter Dimov" <pdimov_at_[hidden]> writes:

> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>> Unspecified, but I don't think we can avoid that with the low-level
>>> interface. High level wrappers that package creation and execution
>>> would be immune to this problem.
>>
>> Is there really a need for a low-level async_call interface?  After
>> all, the existing threads interface provides all the low-levelness
>> you can handle.
>
> I don't know. But the low-levelness contributed by async_call is unique, and
> not covered by boost::thread at present. I'm thinking of the R f() -> { void
> f(), R result() } transformation, with the associated synchronization and
> (possibly) encapsulated exception transporting/translation from the
> execution to result(). 

1. Are you saying you can't implement that in terms of existing thread
   primitives and optional?

2. Is that much different (or more valuable than)

      R f() -> { construct(), R result() }

   which is what I was suggested?

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

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com