RE: [boost] Re: future of boost.threads (implementation)

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2004-02-12 11:20:54

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Peter Dimov

>     register_<exception1, exception2, ...>();
> 
> isn't that hard to implement. But that's not really the point. The point
> is
> that you can place the register_ calls in multiple translation units, and
> you can register_ your library's exceptions even if you don't create any
> threads, and you don't expose their actual types to the world.

Yes, as you point out below I was confusing registration with listing
expected exceptions.  In the implementation I was thinking of there really
is no registration.

> That's the "how" part.

Thanks, that is much clearer now.

> The "whether" part is that we (arguably) need the ability to specify a
> list
> of "expected" exception base classes at thread creation time. I'm still
> not
> sure about that, since this is for all intents and purposes an exception
> specification. Much the same effect can be achieved by just decorating the
> thread function with one.

With a global register and no expected exception list, won't it be possible
for changes in one part of the program to affect which exceptions are
propagated into the calling thread in another part of the program?  Is that
good or bad?

If there is an excepted exception list, do you think it makes sense to have
the library automatically register the types in this list?

Brock