Re: [boost] [transact] code in sandbox

Subject: Re: [boost] [transact] code in sandbox
From: strasser_at_[hidden]
Date: 2010-02-17 11:08:34

Zitat von Vicente Botet Escriba <vicente.botet_at_[hidden]>:

>>>
>>> because of how std::uncaught_exception() works that would
>>> fail if the
>>> macros are used inside a destructor that is called during exception
>>> unwinding:
>>>
>>> http://www.gotw.ca/gotw/047.htm
>>
>> 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.