strasser wrote:
Zitat von Vicente Botet Escriba <vicente.botet@wanadoo.fr>:
because of how std::uncaught_exception() works that would fail if the macros are used inside a destructor that is called during exception unwinding:
I'm familiar with that issue, but I never imagined that would be a reasonable use case. Would you want to encourage using such code in a destructor by this design choice?
I probably wouldn't encourage modifying persistent objects in destructors, but Boost.STM is intended as an alternative to manual thread synchronization. so if you've ever locked a mutex in a destructor, you know a use case for this.
As we cannot throw an isolation_exception, we need to force the transaction to abort. Does this use case responds to the need for force_to_abort/set_rollback_only?
I don't know, as I still don't understand rollback_only. I think Bob's question was about that too. not about the difference between force_to_abort/rollback_only, but the difference between rolling back and marking for rollback.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
abort/rollback will abort the current transaction on the point of call, force_to_abort/set_rollback_only don' make the transaction to abort/rollback immediately, but tell to the the transaction that it must be aborted/rolledback next time we try to commit it. Vicente -- View this message in context: http://old.nabble.com/-transact--code-in-sandbox-tp27515535p27627621.html Sent from the Boost - Dev mailing list archive at Nabble.com.