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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-02-10 17:32:33

David Abrahams wrote:
> "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?

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(); }
};