Re: [Boost-users] asio: transporting exceptions across threads

Subject: Re: [Boost-users] asio: transporting exceptions across threads
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-07-21 17:48:20

Right, the model that fits exception_ptr better is when you have a
thread working on a result which another (main) thread receives; so
the main thread would either get a valid result from a working thread,
or an exception_ptr that describes the reason why the result couldn't
be computed.

>From your description (keep in mind I've never used boost::asio) it
seems that what would work better in your case is to incorporate
exception_ptr into a message of some sort, since it seems like the
worker threads in your case are just parts of a bigger, coherent
system (as opposed to working on individual tasks.)

What should happen when an exception occurs? Should the thread it
occurred in be terminated, or should it simply report the problem and
continue working on something else? What kind of errors are we talking
about? If the user should be notified, perhaps you can create a queue
for worker threads to push exception_ptr objects into, while another
thread pops them from the other side and formats user-friendly
messages?

I'm sure this is perfectly clear to you already, but basically all
that exception_ptr gives you is the ability to hold on to an exception
object as long as you need to, so you can either exit or "keep going"
in the thread where the exception occurred, handing the exception_ptr
to another thread to re-throw it (and use an appropriate catch to deal
with it.)

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode

On Tue, Jul 21, 2009 at 2:16 PM, Zachary Turner<divisortheory_at_[hidden]> wrote:
> On Tue, Jul 21, 2009 at 3:38 PM, Emil
> Dotchevski<emildotchevski_at_[hidden]> wrote:
>> I have never used boost::asio but a complete example of how to use
>> boost::exception_ptr can be found here (see Cloning and Re-Throwing an
>> Exception) :
>>
>> http://www.boost.org/doc/libs/release/libs/exception/doc/tutorial_exception_ptr.html
>>
>> Let me know if this works for you.
>>
>> Emil Dotchevski
>> Reverge Studios, Inc.
>> http://www.revergestudios.com/reblog/index.php?n=ReCode
>
>
> Yea that was the code I was referring to when I was saying I'd looked
> over the tutorial code in the docs.  The problem is that it's
> difficult to explain what the problem is.
>
> Essentially I have N threads.  1 of these we can consider the "master"
> thread, which is also the main application thread.  The other threads
> are all worker threads in some form or another.  In order to "start"
> asio, you at some point run this function which is essentially an
> event loop that doesn't return until it runs out of work to do, or
> until an exception propagates outside of the event loop.
>
> The model in place is that you run this event loop in each thread that
> is supposed to participate in asio.  So, with the exception of the
> main application thread, I've created all of these worker threads with
> a very simple thread start routine function that all it does is run
> the event loop.
>
> In the example in the documentation, it relies on the fact that there
> is a well-defined sequence point at which the main thread can call
> thread::join on the child thread.  But this doesn't really happen in
> asio.  Nothing in the parent thread's handlers or worker code has any
> idea that other threads are running at all.  I can let the exception
> propagate all the way out of my worker thread's event loop and have
> the thread function just return, but then the parent thread hangs
> because it posts a message to this service and the service just
> doesn't respond.
>
> It's also not clear how such error handling will play well with the
> fact that there's many different threads running.  For example, I
> encounter the error in worker thread B, and thread A is trying to post
> a message to thread B at the same time.  If I simply shut thread B's
> service down when I encounter the error, is this goign to exhibit
> well-defined behavior?
>
> I've thought of a couple of possible ideas, but all of them seem
> hackish and I'm not sure how well they'll scale.  Some of them I've
> tried, but then asio encounters weird issues in the destructor of one
> of its internal classes called service_registry.
>
>
> Was hoping someone had encountered this before and come up with something.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users