Re: Boost.threads - a couple questions / minor doc issues

From: williamkempf_at_[hidden]
Date: 2001-11-29 10:11:42

--- In boost_at_y..., "Jeff Garland" <jeff_at_c...> wrote:
> 
> I finally got a chance to look over the thread library a bit.  
Overall, it looks
> like a nice start. Here are a couple of things I noticed.
> 
> 1) First, on the Rationale page under the comparison of ref-
based/versus
> non-copyable design there is a bug in the code example:
> 
> 5.
> void foo()
> {
>    thread thrd* = new thread(&bar);
>    manager.owns(thread);      // oops should be thrd not thread!
> }

Thanks, I'll fix this one.

> 2) Also, I found the "psuedo-code" section distracting.  It was a 
little too
> close to real C++ that when I missed the word "psuedo" I found 
myself wondering
> what "thread = create_thread(&bar);"  meant.  Anyway, I finally 
went back and
> understood, but at the end of the day, I think the psuedo code 
could be removed
> and the documentation would be easier to read and just as 
illustrative.

There may be a complete re-write of this rationale.  Other's have not 
cared for other aspects of it.  I'll table this suggestion until I 
can evaluate what direction I want to go with this portion of the 
documentation.
 
> 3) In the xtime.html page under Example Usage the header link
> (<boost/thread/xtime.hpp) actually links to tss.hpp.

Thanks, I'll fix this.
 
> 4) Finally, I have a question about the time related interfaces.  
The current
> Boost.threads requires the client to provide an "expiration time" 
(type
> boost::xtime) for sleep and timed_locks.  I was rather surprised 
that this
> interface was not specified in terms of a time duration like:
> 
>   sleep(boost::time_duration)
> 
> where time_duration would hold the number of nano seconds to 
sleep.  This would
> be a more traditional interface to sleep and would remove the 
burden on client
> programmers that need to "sleep for 2 seconds" from calling 
xtime_get and
> performing addition to the xtime struct.  Anyway, I was just 
curious about the
> design motivations here.

Consistency.  The condition timed waits *must* be in absolute time 
format since they are used in loops where the burden of re-
calculating the duration everytime would be too great (not to mention 
too likely to be a source of error).  Once that's chosen it becomes a 
little confusing to turn around and use durations for all other timed 
operations.  I brought this up on the list during design and got 
little opinion from anyone, but what little I did get suggested that 
consistency was more important here and thus the decision was made.  
We're early enough in the libraries life cycle to reconsider this 
decision if you want to start discussion here.  However, if the pain 
of calculating a duration is your only concern I expect this to be 
resolved with a Boost time/duration concept.

boost::timed_mutex::scoped_timed_lock lock(mx, boost::time
().add_milliseconds(50));

Or some similar syntax.

Thanks for your comments,
Bill Kempf