From: John Max Skaller (skaller_at_[hidden])
Date: 2001-06-28 15:58:47
> 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?
> 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,
> 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 http://felix.sourceforge.net Literate Programming tool Interscript http://Interscript.sourceforge.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk