Solved: exception lifetime rules unclear - Page 2

Steve_Nuchia · ‎08-04-2009

Yes, it's me with yet another queston about exceptions.

Several of us, all with quite a bit of experience but all new to TBB, have studied the available documentation on the TBB exception mechanism and we're all confused about lifetime management.

Did we miss something? Is there a succinct rule that we should memorize?

In order to retrofit parallel constructs into a legacy Windows GUI program I'm wrapping all the algorithms. Our code has historically caught certain exceptions above the layer I'm working at, cancelling a "task" but continuing the session. So the potential exists for an arbitrary number of exceptions to be thrown, so I really want to avoid creating a leak here.

Thanks,
-swn

Andrey_Marochko · ‎08-13-2009

Quoting - Steve Nuchia

Something is still missing here. After calling my_2nd_copy->throw_self() I lose control. Is it the responsibility of the catch block to call destroy? If so, enforcing that throughout close to five million lines of code is going to be a challenge.

Well, TBB, as most of other more or less successfull (in terms of adoption) libraries, always is challenged with striking a good balance between usability (or ease-of-use) / efficiency (performance) / richness of functionality. As the popular sayng goes: pick up any two of them. In practice achieving this good balance usually means that you have to favor most frequent use cases that cover the largest part of the application field.

Your use case does not fall into this category :), but nevertheless it is supported, right? Of course completely automatic lifetime management would be great, but this means garbage collection. Obviously this is inacceptable solution for a compact library not tied to a particular compiler, runtime, or OS. You need to destroy the object pointed to by my_2nd_copy at any time after my_2nd_copy->throw_self() is invoked (including inside the catch block - because the catch block operates with the copy created by compiler). This can be done in any thread of the application.

View solution in original post

Steve_Nuchia · ‎06-10-2011

wait a minute .. what if what I throw not "throw_self" but a smart pointer to the moved exception? That object lives until the final catch, carries with it all the available context, and calls destroy at the right time. that would work, at the cost of requiring an oddball catch signature. But for the case I'm worried about, moved exceptions being caught by legacy default catch blocks, it would do the right thing.

Steve_Nuchia · ‎06-10-2011

http://threadingbuildingblocks.org/files/documentation/a00172.html

See the sentence tagged "IMPORTANT" ... any function catching and re-throwing an exception that might have been moved needs to know not only whether or not it was moved but also whether it was invoked from inside a task.

How? How is it supposed to know these things?