Re: [boost] Re: Boost.Threads - thread_desc concept

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;

        Semantics?
 
>         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  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net