Boost logo

Boost :

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-06-28 15:58:47

williamkempf_at_[hidden] wrote:

> Considering all of the discussion so far, I think this slightly
> modified interface is the best design so far:
> class thread : boost::noncopyable
> {

        What? only one kind of thread allowed?
        Shouldn't this class use pure virtual methods?

> public:
> thread(detail::threadproc proc); // Starts the thread

        Prevents wrapping native thread handle.
        Doesn't allow any data to be passed to the thread.

> ~thread(); // If not detached, detaches the thread
> // To allow us to not need self(), at least for
> // comparison.
> bool is_current() const;

> bool is_alive() const;

        Semantics? This is slippery. A return value of 'true' is useless.
Only a return value of 'false' is useful, and 'true' must be
returned even if the thread is not started yet.
> // Waits for the thread to finish and then calls detach()
> void join();

        No. Ensures the thread is detached.

        If the thread is already detached, just return.

> // I have a feeling this one should go away with this
> // design, but again I'll leave it in for discussion.
> static void join_all();

        I agree with your feeling. Normative semantics
are questionable: I guess it must refer to threads
which have 'thread' class objects as wrappers.
> // These two can probably become free standing methods,
> // though I like the encapsulation.
> static void sleep(const xtime& xt);
> static void yield();

        Friends have the same status.

> 1) Will other operations that can be performed on threads create a
> very real need for a self() method?

        Of course. [I'd call it 'get_native_id()']

> 2) Should there be a join_all().
>I'm becoming convinced there
> shouldn't be for various reasons,

        I agree.

> 3) Should there be comparison operators? With out copy semantics
> you'd always be comparing to yourself, so I'd guess not.

        Correct with the current design.

> 4) Will the usage of this design make users opt for the native C
> APIs instead of the Boost.Threads library.

        In some cases. This is unavoidable. The worst problem
is thread creation.

> 5) Are the join(), detach() and destructor semantics understandable
> and usable?

        join and detach should NEVER give an error.
They should 'ensure' that IF they return, THEN a certain
invariant holds (namely, the designated thread is not
in a non-detached state: it is detached, dead, or
otherwise beyond control of this class)

        It is important to note I think that IF the designated
thread has not started, they wait first until it starts,
THEN wait until it is detached.

John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix
Literate Programming tool Interscript

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