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

From: Wolfgang Bangerth (bangerth_at_[hidden])
Date: 2003-02-06 15:34:09

> > >   async_result<double> later = spawn(foo)(a, b, c);
> >
> > Mustn't use the name spawn() here.  It implies a thread/process/what ever
> > has been spawned at this point, which is not the case.  Or has it (he says
> > later, having read on)?
> 
> It has.

It must, because a/b/c might be temporaries. You must have started the new 
thread and copied the arguments to the new thread before you can return 
from the spawn call, since otherwise the temporaries might have been 
destroyed in the meantime.

> Sorry, IMO there's nothing "obvious" about your syntax.  It looks cumbersome
> and low-level to me.

Right. That's exactly my criticism. Calling a function on a new thread 
should be just as simple as calling it sequentially. And
    spawn(foo)(a,b,c);
i.e. not using the return value, should just create a detached thread.

> I'm sure I'm never biased <wink>, and I tend to like your syntax better.
> However, I recognize what Bill is concerned about.  Let me suggest a
> compromise:
>
>  async_result<double> later = spawn(foo)(a, b, c);
>  ...
>  thread& t = later.thread();
>  // do whatever with t
>  ...
>  double now = later.join();  // or later.get()

The way I went is to derive async_result from thread, so you get the 
.thread() function for free as a derived-to-base conversion. Actually,
async_result<>=thread<> and thread=thread_base in what I have, but that's 
just naming.

> You could also consider the merits of providing an implicit conversion 
> from async_result<T> to T.

Possible, but I'd say too confusing.

Cheers
  W.

-------------------------------------------------------------------------
Wolfgang Bangerth             email:            bangerth_at_[hidden]
                              www: http://www.ticam.utexas.edu/~bangerth/