Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)

Subject: Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-02-21 19:02:05

Hi,
----- Original Message ----- 
From: <strasser_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, February 21, 2010 11:21 PM
Subject: Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)

> 
> the changes we've discussed:
> 
> https://svn.boost.org/trac/boost/changeset/59827
 
I have used this enumeration 
enum control_flow {
    none,
    break_,
    continue_
};

I suggest you use the same to avoid code using constants as 0, 1,2. 
 
> Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:
> 
>> Yes, we can. But the result of the break is that we don't retry,  
>> i.e. we abort the transaction. If you prefer you can throw an  
>> isolation_exception when the user uses break or continue instead of  
>> asserting it don't use it.
> 
> I'm pretty sure you're trying to stop the user from shooting himself  
> in the foot here.
> instead of "break", the user could also "return" from a retry clause.  
> or throw an exception and absorbing it outside of the transactino  
> scope, with similar results.
> I think "break" should break, not assert and not throw, just because  
> we think this is what the user should have done.

The difference is that the user would not write a retry block on a sequential program, retry is specific of transactions. As we are not used to work with retry, maybe the best is to allow it to choose if s/he prefer to let break/continue to be used, asserted or throw an isolation_exception. The default could be to exit the user loop. What do you think?
 
>>> try{
>>>   //...
>>> }catch(my_exc &){
>>>   transaction{
>>>     //...
>>>   }retry{
>>>     throw;
>>>   }
>>> }
>>>
>>> is it expected behaviour that this rethrows isolation_exception, not my_exc?
>>
>> yes, IMO the exception must be isolation_exception, or a specific  
>> exception the library documents and make the outer transaction to  
>> abort.
> 
> OK. moved the user's retry code back into the catch-clause.

A minor detail to the new implementation. The body of a retry statement should IMO be a compound statement if we want follow the C++ catch grammar.

      }catch(boost::transact::isolation_exception &___i){ \
        ___i.unwind<TXMGR>(); \
        do{ \
          ___control=1; \
          if(false);else

Instead of 
          if(false);else
you can do
          try {throw;}catch (boost::transact::isolation_exception &)
    

I have a question related to unwind. Instead of 

   }catch(boost::transact::isolation_exception &___i){ \
    ___i.unwind<TXMGR>(); \

I have the equivalent of
   } catch (boost::transact::isolation_exception &) { \
     if (__tx.is_nested()) throw; \

is_nested returns true if the transaction is not a root tra,nsaction.

Does unwind do exactly the same? If this is not the case could you explain what unwind does?

Best,
Vicente