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

From: Darryl Green (green_at_[hidden])
Date: 2002-08-12 03:28:40

> -----Original Message-----
> From: William Kempf [mailto:williamkempf_at_[hidden]]
> 
> >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.
> 

I want to something expected, not something unexpected (async exceptions).
It depends what you mean by recover - I just don't want to die an
uncontrolled death.

> > >   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?

Sorry. I should have been more explicit. I'm assuming here that this
hypothetical lib I'm trying to use is *not* a lib that specifically deals
with async function execution it is just a user of it and intends
to/attempts to insulate the user from it, possibly by using some handy
library(s) to do it. So the "Which lib?" was - can the database access
library delegate this problem to some other lib and if so which lib.
> 
> >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.
> 

I don't know about everybody - I was purposely not being specific about the
actual mechanism that lead to there being a thread with an exception being
thrown from it. As it happens I *am* using thread_pool for async function
invocation at present.

> >What about some
> >sort of futures object?
> 
> What do you mean by "futures" object?

A future is an async return value that may not be there yet (unless you need
it to be)...

> 
> >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.

I hope you have lost me here. Surely it is reasonable for someone just to
want to know how in a pretty superficial way (point me at the example, not
understand the mechanism)?

> 
> >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.

So did I miss some difference? As I said, If there are lots of differences,
consistency isn't viable.

> 
> > > 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.

I think before you can be that pedantic you are going to have to define what
is and isn't an async call in this context ( rather than in some other
thread :-) ).

> 
> >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.

I think this is the nub of it. According to your claim I should be able to
write appropriate function objects to produce similar results independent of
the mechanism. This I agree with.
I still find it perverse that the "safe thing to do" if a poorly written
thread throws an exception is to crash the other threads (for the lack of a
better term for the state of the system when terminate() is called).
However, it seems this is beyond the power of your lib to deal with, so I'll
let you off :-)
 
Regards
Darryl Green.