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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-06 10:38:38

>
>> >     double d;
>> >     thread<double> t = spawn(foo)(a,b,c);
>> >     // do something else
>> >     d = thread.return_value();
>>
>> A solution like this has been proposed before, but I don't like it.
>> This creates multiple thread types, instead of a single thread type.
>> I think this will only make the interface less convenient, and will
>> make the implementation much more complex.  For instance, you now must
>> have a seperate thread_self type that duplicates all of thread<>
>> except for the data type specific features.  These differing types
>> will have to compare to each other, however.
>
> Make the common part a base class. That's how the proposal I sent you
> does  it :-)

Simplifies the implementation, but complicates the interface.

>> async_result<double> res;
>> thread t(bind(res.call(), a, b, c));
>> // do something else
>> d = res.value();  // Explicitly waits for the thread to return a
>> value?
>
> This does the same, indeed. Starting a thread this way is just a little
> more complex (and -- in my view -- less obvious to read) than writing
>   thread t = spawn(foo)(a,b,c);

Not sure I agree about "less obvious to read".  If your syntax had been
   thread t = spawn(foo, a, b, c);
I think you'd have a bit more of an argument here.  And I certainly could
fold the binding directly into boost::thread so that my syntax would
become:

thread t(res.call(), a, b, c);

I could even eliminate the ".call()" syntax with some implicit
conversions, but I dislike that for the obvious reasons.  I specifically
chose not to include syntactic binding in boost::thread a long time ago,
because I prefer the explicit seperation of concerns.  So, where you think
my syntax is "less obvious to read", I think it's "more explicit".

> But that's just personal opinion, and I'm arguably biased :-)

As am I :).

>> Hopefully you're not duplicating efforts here, and are using
>> Boost.Bind and Boost.Function in the implementation?
>
> Actually it does duplicate the work, but not because I am stubborn. We
> have an existing implementation for a couple of years, and the present
> version just evolved from this. However, there's a second point: when
> starting threads, you have a relatively clear picture as to how long
> certain objects are needed, and one can avoid several copying steps if
> one  does some things by hand. It's short anyway, tuple type and tie
> function  are your friend here.

I'm not sure how you avoid copies here.  Granted, the current
implementation isn't optimized in this way, but it's possible for me to
reduce the number of copies down to what I think would be equivalent to a
hand coded implementation.

>> >     thread<> t = spawn(foo)(a,b,c);
>> >     t.yield ();    // oops, who's going to yield here?
>>
>> You shouldn't really ever write code like that.  It should be
>> thread::yield().  But even if you write it the way you did, it will
>> always be the current thread that yields, which is the only thread
>> that can.  I don't agree with seperating the interfaces here.
>
> I certainly know that one shouldn't write the code like this. It's just
> that this way you are inviting people to write buglets. After all, you
> have (or may have in the future) functions
>   t->kill ();
>   t->suspend ();
> Someone sees that there's a function yield() but doesn't have the time
> to  read the documentation, what will he assume what yield() does?

How does "someone see that there's a function yield()" with out also
seeing that it's static?  No need to read documentation for that, as it's
an explicit part of the functions signature.

> If there's a way to avoid such invitations for errors, one should use
> it.

I understand the theory behind this, I've just never seen a real world
case where someone's been bitten in this way.  I know I never would be. 
So I don't find it very compelling.  But as I said elsewhere, I'm not so
opposed as to not consider making these free functions instead because of
this reasoning.  I would be opposed to another class, however, as I don't
think that solves anything, but instead makes things worse.

-- 
William E. Kempf
wekempf_at_[hidden]