"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Peter Dimov" <[EMAIL PROTECTED]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
