Boost logo

Boost :

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-15 01:45:59


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_at_[hidden]>
> >
> > 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



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk