Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at