[boost] Re: future of boost.threads

From: Burc Arpat (burch_at_[hidden])
Date: 2004-02-09 18:08:24

> "Is everyone convinced that propagating the exception into the joining thread
is the right behavior or even semantically sensible?"

as a novice user of concurrent programming ( especially when compared to the
level here in the boost list ), may i ask whether it is going to be possible to
identify the throwing thread or not?

here's why i am asking this: let's say i have two threads reading two different
files and one of them throws ios_base::failure.  this information by itself is
meaningless if i catch it in the master thread as i don't have a way of
identifying the source.  currently, we employ a different mechanism ( using
pthreads for now; wishing to switch to boost.threads ): each thread has its own
error code in a shared container and if they want to report an error, they write
to that container.  that way, we know which thread is reporting what error and
we can handle it.  elegant?  not at all but it works

so i wonder if propagating exceptions from worker threads to the master thread
is gonna have some comparable functionality? ( worker/master architecture is the
only model we commonly use so i can't really talk for other thread architectures
).  if it doesn't, i think the best a programmer like myself can do is to catch
( ... ) and then still use the shared error code container to resolve the issue

am i misunderstanding this mechanism or is it gonna be like i described above?

burch

> Stefan Seefeld <seefeld <at> sympatico.ca> writes:
> 
> > Glen Knowles wrote:
> >> From: David Abrahams [mailto:dave <at> boost-consulting.com]
> >>  >> Of course you cannot portably pass all exceptions, but you may be able
> >>  >> to pass all the ones that use standard types.
> >>  >
> >>  >And what if the std library or somebody else throws exceptions
> >>  >*derived* from the standard types?
> >> If it is not a recognized corba exception what the ACE TAO does is
> >> eat it with a catch(...) and then throws a corba system exception on
> >> the other side.
> >
> >
> > yes, so all exceptions that are allowed to pass have to be explicitely
> > declared
> > as such. If it is not declared, a special standard exception will be
> > thrown (or may be something equivalent to 'unexpected'). If it is
> > derived from a declared one, it will be sliced.
> 
> Is everyone convinced that propagating the exception into the joining
> thread is the right behavior or even semantically sensible?