Re: [boost] [transact] code in sandbox

Subject: Re: [boost] [transact] code in sandbox
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-02-17 12:50:36

strasser wrote:
> 
> 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.
> 
> 
> _______________________________________________
> 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.