Boost logo

Boost :

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-
> 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

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
> 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"
> 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

Or some similar syntax.

Thanks for your comments,
Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at