RE: [boost] Re: future of boost.threads
-----Original Message----- From: Peter Dimov [mailto:pdimov@mmltd.net] [snip] Now, in C++ functions actually can return either a value or an exception. That is, int f(); can return an int or throw an exception. Hence, when you execute that f in a thread, you should be able later to call
int thread::join();
and it should return whatever f returned.
Yes. I think you mentioned this last time exception propogation across threads was discussed, and I agree. I seem to recall that William Kempf was keen to shift the burden of these sorts of things to some form of wrapper/function object (see http://article.gmane.org/gmane.comp.lib.boost.devel/14237).
Note that you can't add exception marshalling on a higher level (with the current interface) because you can't access a thread's state (to retrieve its return value or exception) from another thread.
Can't some function object wrapper catch and store the exception somewhere other than in the "thread state" for later access from some sort of async call object regardless of the underlying thread implementation? The joining thread would wait on one of these async call objects (ie join). The async call object and the wrapper would have shared access/ownership of the result (exception or return value) storage. What am I missing? Regards Darryl Green. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################
Darryl Green wrote:
Can't some function object wrapper catch and store the exception somewhere other than in the "thread state" for later access from some sort of async call object regardless of the underlying thread implementation?
The joining thread would wait on one of these async call objects (ie join). The async call object and the wrapper would have shared access/ownership of the result (exception or return value) storage.
What am I missing?
to 'catch and store' an exception, i.e. to take it out of its (C++) call stack, you need a 'virtual constructor' of some sort, so the exact type is remembered in the clone (which is not just a slice of a common base class) and can be re-dispatched in a different context, i.e. the joining thread. Regards, Stefan
Darryl Green wrote:
-----Original Message----- From: Peter Dimov [mailto:pdimov@mmltd.net] [snip] Now, in C++ functions actually can return either a value or an exception. That is, int f(); can return an int or throw an exception. Hence, when you execute that f in a thread, you should be able later to call
int thread::join();
and it should return whatever f returned.
Yes. I think you mentioned this last time exception propogation across threads was discussed, and I agree.
Indeed I did. :-)
I seem to recall that William Kempf was keen to shift the burden of these sorts of things to some form of wrapper/function object (see http://article.gmane.org/gmane.comp.lib.boost.devel/14237).
The problem is that boost::threads does not give you access to the function object. If it did you could've emulated the functionality from user space with something like boost::thread th( wrap_function(f) ); and later wrapped_function<int> * pw = th.join(); int r = pw->return_value();
Note that you can't add exception marshalling on a higher level (with the current interface) because you can't access a thread's state (to retrieve its return value or exception) from another thread.
Can't some function object wrapper catch and store the exception somewhere other than in the "thread state" for later access from some sort of async call object regardless of the underlying thread implementation?
The function object is part of the thread state. In theory, as boost::threads is about equivalent in expressive power to pthreads, you can implement boost::threads2 on top of the low level boost::threads. But that's just doing the work twice for no apparent benefit.
participants (3)
-
Darryl Green -
Peter Dimov -
Stefan Seefeld