David Abrahams wrote:
> "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?
I can. On the other hand, I can implement the thread primitives and
optional, too. The point is that if, while building a high-level interface
implementation, we discover an useful low-level primitive that offers
greater expressive power (if less safety), we should consider exposing it,
too, unless there are strong reasons not to.
> 2. Is that much different (or more valuable than)
>
> R f() -> { construct(), R result() }
>
> which is what I was suggested?
I don't know. Post the code. ;-) You can use stub synchronous threads and
thread_pools for illustration:
struct thread
{
template<class F> explicit thread(F f) { f(); }
};
struct thread_pool
{
template<class F> void dispatch(F f) { f(); }
};
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
