Re: [boost] Re: RFC: Multithreading design constraints

From: Beman Dawes (beman_at_[hidden])
Date: 2000-06-06 10:44:03

At 03:58 PM 6/6/00 +0200, Branko =?iso-8859-2?Q?=C8ibej?= wrote:

>> Let me make sure I understand (1). Are you saying that the
apparent
>> thread startup function is actually called from a private library
>> startup function which wraps the call to the apparent startup
>> function in a try...catch?  Hum. That does seem like a good idea!
>
>Yes -- that would be necessary for all three scenarios.
>
>Even without exception support, it makes sense to wrap the call to
the
>startup function like that. I was thinking about something like this
>(e.g., for 2 -- not tested):
>
>	class thread
>	{
>	  public:
>	    thread()
>		: exception_thrown(false),
>                  self(invalid_thread)
>	        {}
>	    virtual ~thread() {}
>
>	    void run() {
>	        self = create_thread(start_thread, this);
>	    }
>	    void join() throw(runtime_error) {
>	        wait_for_thread(self);
>	        self = invalid_thread;
>		if (exception_thrown)
>		    throw runtime_error("unhandled exception in thread");
>	    }
>	    virtual void main() = 0;
>
>	  private:
>	    bool exception_thrown;
>	    thread_handle_t self;
>	    static void start_thread(void* arg) {
>	        thread* thr = dynamic_cast<thread*>(arg);
>	                      // This cast should always succeed, right?
>	        exception_thrown = false;
>		try {
>	            thr->main();
>                } 
>	        catch(...) {
>	            thr->exception_thrown = true;
>	        }
>	    }
>	};
>
>
>(With appropriate locks to protect the class' internal data.)

Yes, modulo details, that looks promising.  Would it be a bit safer
if start_thread were a non-member function?  Even though it is
static, it still has to be called by what is probably a C function
like pthread_create in create_thread, and that strikes me as a
possible source of undefined behavior (although I didn't try to
puzzle through what the standard says about it).

--Beman