RE: [boost] Re: Re: Re: Threads & Exceptions

From: William Kempf (williamkempf_at_[hidden])
Date: 2002-08-11 23:47:17

>From: Darryl Green <green_at_[hidden]>
>I don't want to restart the thread (as such). My concern about this is that
>some library author decides it is a really great idea to replace a function
>that was running in the calling threads context with one that runs async 
>(in
>some sense). As a user of the func, I have been prepared to deal with its
>failure (throwing exception) somehow. The func itself doesn't know how to
>deal with its own failure - thats why it lets the exception propogate...

And again, assuming the library called the appropriate polling methods to 
cause the exception to cross the thread boundaries (hint... async exceptions 
are not something I think anyone will accept in C++ once they've thought it 
through... especially not with major language changes), and you thus catch 
the exception, how do you presume to recover here?  Unless the library 
provides a means to recover, there's nothing you can do about it.

> >   If you could restart the thread, that means you must have
> > been the one to
> > start it, and thus you could wrap it to prevent exceptions
> > from calling
> > terminate().
>
>The *library* started the thread. It would need to wrap it. I agree it
>could. Which lib?

Didn't you just say the lib that started the thread?

>How?

Wouldn't that be up to the library and be dependent on what the needs are?

>Will every lib do this differently?

Quite possibly, and possibly for good reason as well.

>Will Dave Moore's
>thread pool support some method of doing this for funcs launched that way,
>and some other async execution model use another method?

Possibly.  Though this argues further that the mechanism for transferring 
exceptions belongs somewhere other than the thread class.  The thread_pool 
actually insures that the threads don't die on uncaught exceptions, because 
this *is* the async call that everyone's imagining that thread creation is.  
That's part of the reason I believe functionality like this belongs in a 
function object wrapper.

>What about some
>sort of futures object?

What do you mean by "futures" object?

>Does any of this need boost::thread support?

No, not as far as I can see.

>The
>library writer who uses any of these other libraries in writing something
>that has nothing to do with threads as-such isn't the person best placed to
>decide how to do this and/or how to implement it.

Seems to me like they are.

>The user just wants
>consistent behaviour.

I don't see that that's precisely true.  Put another way, I see consistancy 
where it should exist, and differences where it should not.

> > I understand why people think that async calls should throw,
> > but again,
> > threads are not async calls in the fashion that people are thinking.
>
>No, but they underly them.

Actually, they don't.  There are numerous ways to make a call asynchronous.

>If it is your considered opinion that the issues above can be, and are 
>best,
>solved outside of boost:thread I'm quite prepared to stop heckling. If you
>have already made such a claim I have missed it while following in the
>standards related debate.

I've made the claim before, and I reiterate now, async behavior (including 
error handling, which may or may not be in the form of exceptions) belongs 
in a function object wrapper.  Threads, thread pools, RPCs, message 
dispatching systems or other mechanisms I'm not thinking of should only be 
used as the means for making such calls (at least appear) to execute 
asynchronously, while the function object provides a consistent interface 
for dealing with the complex issues of handling errors and exceptions.

Bill Kempf
williamkempf_at_[hidden]

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com