Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-09-01 09:26:57

Roland Schwarz <roland.schwarz_at_[hidden]> writes:

> David Abrahams schrieb:
>>Not from a portable C++ point-of-view, no.
>>A platform or C++ implementation is free to implement its own
>>swallowing, so there's no guarantee that there will be less error
> I am not sure I got the point, please keep patient:
> Wouldn't this imply that a particular C++ compiler does know about
> threading at a specific platform?

>From an abstract, portable C++ POV that's certainly possible.

> I always was thinking that current compilers are thread unaware at
> all?

I'm not sure. I think some may, e.g., protect static initializations.
I know that some have an EH mechanism that's bound to pthread

> Only libraries e.g. built around pthreads made the connection
> between C++ and threading so far.
> Could you please give me an example where this is substantially
> different? I.e. where the ending of a thread will not swallow
> uncaught exceptions?

I don't have one.

> But please don't get me wrong. I am not advocating to remove the
> catch all.

I am.

> I can see the potentially undefined behaviour if it were
> removed. I just don't think that it will have a big impact from a
> practical perspective.
> Also I cannot understand how a C++ compiler should be able
> to detect that a thread has ended and call the respective
> process shutdown if there are any uncaught exceptions.

It's known as "compiler magic."

>> You can just put the try/catch in your thread main function and call
>>the shutdown function from there.
> But this would force a user to use platform specific code in his
> program, wouldn't it?

Not unless you think the shutdown function is platform specific. But
anyway, Boost.Thread never promised to protect users from ever having
to write platform-specific code.

> The boost thread does not have a dedicated function for process tear
> down. And I doubt the standard does say anything about process tear
> down in the presence of threads.

Urr, abort(), terminate(), and exit() all come about as close as you
could want to addressing process termination.

> On the other hand the process tear down could be put into the catch all
> clause of the thread proxy. Unfortunately this will be a _big_ change from
> a user perspective.

And having any catch all clause at all will prevent us from reaching
other goals desired by the instigators of this thread.

> What about adding a dedicated process tear down function to the
> library? This function could be called by the user if needed.

What's wrong with what the standard provides?

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at