Results:

Without the pthread_exit (0):

constructor
destructor
destructor
Segmentation fault

With the pthread_exit (0):

constructor
destructor
this is at test_exception!
destructor

Source:

#include <iostream>
#include <pthread.h>

#include <stdexcept>

std::exception* passed_exception;

struct test_exception : public std::exception {
        test_exception () {
                std::cout << "constructor" << std::endl;
        }

        ~test_exception () {
                std::cout << "destructor" << std::endl;
        }

        char const* what () const {
                return "this is at test_exception!";
        }
};

void* threadProcess (void* typelessPointer) {

        try {
                throw test_exception ();
        }
        catch (std::exception& exception) {
                passed_exception = &exception;
                pthread_exit (0);
        }
        catch (...) {
                std::cout << "terminate ()" << std::endl;
        }

return 0;
}

int main () {

        pthread_t thread;
        pthread_create (&thread, 0, threadProcess, 0);
        pthread_join (thread, 0);

std::cout << passed_exception->what () << std::endl;
delete passed_exception;

return 0;
}

----- Original Message -----

From: Eric Woodruff

Newsgroups: gmane.comp.lib.boost.devel

Sent: Wednesday, 2002:August:14 7:12 PM

Subject: Re: std::exception -- Re:Re:Re:Re:Re:AttemptingresolutionofThreads&ExceptionsIssue

I just had a thought. What is the behavior of a thread_exit () type method?
What happens if a std::exception& is caught to hold onto the address, and in
the catch block, thread_exit () is called? Will this bypass the exception
handler destructing the exception, keeping it available for the thread<> to
destruct it lator? If not is there a way to do that? Portably? If so, is it
legal to delete the std::exception* that we held on to or is that object
memory sacred because it is in a "special" place?

----- Original Message -----
From: Peter Dimov
Newsgroups: gmane.comp.lib.boost.devel
Sent: Wednesday, 2002:August:14 4:18 PM
Subject: Re: std::exception -- Re:
Re:Re:Re:Re:AttemptingresolutionofThreads&ExceptionsIssue

From: "David Abrahams" <dave@boost-consulting.com>
> >
> > Well, I am not a compiler writer, but it seems to me that to implement
> > "throw;" and "catch", the compiler already needs a way to copy the
> > exception, complete with its original type. :-)
>
> Of course, but there's a lot more to it than that!
> How would you use the existing constructs to propagate an exception across
> threads? Show me the code that should have the semantics you'd like to
see.
> In particular, please show how the exception arrives at its destination.

I can't really answer these questions because I'm not sure of the meaning
behind "existing constructs", "propagate an exception across threads",
"arrives at its destination."

What we need:

int f()
{
    throw 5; // #1
}

int main()
{
    thread t(f);

    try
    {
        std::cout << t.join() << std::endl; // #2
    }
    catch(int x)

    {
        std::cout << x << std::endl;
    }
}

Now, at #1, the compiler needs to make a copy of '5' and store it somewhere
where the stack unwinding doesn't destroy it, right? Threads can see the
whole process memory (visibility issues notwithstanding), so at #2, t.join()
can execute the equivalent of "throw;" using the stored exception. There are
two threads, but only one C++ program, so the catch clause will be able to
handle the exception.

A library solution needs to use dynamic allocation and clone() to preserve
the exception, and a virtual throw_this() to execute the rethrow, but a
compiler should be able to do better than that.

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost