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

From: Darryl Green (Darryl.Green_at_[hidden])
Date: 2003-02-09 20:50:43

> -----Original Message-----
> From: William E. Kempf [mailto:wekempf_at_[hidden]]
>
> > .. borrowing Dave's async_call syntax and Alexander's
> > semantics (which aren't really any different to yours):
> 
> Dave's semantics certainly *were* different from mine (and the Futures
> link posted by Alexander).  In fact, I see Alexander's post as
> strengthening my argument for semantics different from Dave's.  Which
> leaves us with my semantics (mostly), but some room left to argue the
> syntax.

Isn't that what I said? In any case it is what I meant :-)

> 
> > async_call<double> later1(foo, a, b, c);
> > async_call<double> later2(foo, d, e, f);
> > thread_pool pool;
> > pool.dispatch(later1);
> > pool.dispatch(later2);
> > d = later1.result() + later2.result();
> 
> You've not used Dave's semantics, but mine (with the variation of when
you
> bind).

Yes - I thought I said I was using Alexander's/your semantics? Anyway
the result is it looks to me like we agree - so I'll go back to
lurking...

> 
> >> More importantly, if you really don't like the syntax of my design,
it
> > at
> >> least allows you to *trivially* implement your design.  Sometimes
> > there's
> >> something to be said for being "lower level".
> >
> > Well as a user I'd be *trivially* implementing something to produce
the
> > above. Do-able I think (after I have a bit of a look at the innards
of
> > bind), but its hardly trivial.
> 
> The only thing that's not trivial with your syntax changes above is
> dealing with the requisite reference semantics with out requiring
dynamic
> memory allocation.  But I think I can work around that.  If people
prefer
> the early/static binding, I can work on this design.  I think it's a
> little less flexible, but won't argue that point if people prefer it.

I'm not sure that it is flexible enough for everyone - I was just
putting up a "what one user would like" argument. I see that Dave wants
results obtained from/as a function object for a start - and I'm
prepared to believe that that is more important than whether the syntax
is a little odd/inside-out at first glance.

Regards
Darryl Green.