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: strasser_at_[hidden]
Date: 2010-02-21 11:37:41

Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:
>> inside the retry-clause the transaction object is destructed and no
>> new one is constructed yet. STM could provide an API for setting the
>> priority of the next transaction, using thread-specific storage to
>> support this.
>
> I would prefer the transaction be available on retry. Of courset,  
> this need to have a restart function.

to me this seems similar to

if(int v=f()){
   //...
}else{
   //v is not in available here.
}

since the retry{} clause is syntactically a new scope.

>>> * Should the following compile?
>>>
>>> begin_transaction
>>>    statement1;
>>>    statement1;
>>> end_transaction;
>>>
>>
>> it currently does. if we want to adhere to the syntax of a language  
>> extension:
>>
>> transaction /statement/
>>
>> we could enforce this by wrapping the user code in

>     if(false);else
> works as expected.

ok, will add that.

> There is yet a drawback to your current implemntation:
> * when the commit done on the destructor of the  
> commit_on_destruction variable fails, you will throw an exception on  
> a destructor. If the destructor is called due to a thrown exception  
> the program will terminate. So, ~commit_on_destruction() should not  
> throw.

this can not happen. see the call to nullify(). the whole lifetime of  
commit_on_destruction is wrapped in a try{} clause. if it throws,  
commit_on_destruction is nullified.
so ~commit_on_destruction does not throw if the scope is exited by  
exception, and I see no problem with throwing from a destructor  
otherwise, not even in the case the macros are used in user's  
destructors.
am I missing something?

> I have resumed in the following pseudo code the code generated by my  
> macros depending on whether
> * the current transaction block is in a loop IN_LOOP
> * there are specific exception hadlers HANDLER_SEQ
> * there is a specific retry (RETRY)

I don't quite understand what you're trying to say in this paragraph  
and the following pseudo code. defining a grammar for language  
extension/code transformation, or anything directly related to the  
macros?

could you please comment on the following case, as I'm not sure what  
the solution is:

for(...){
   begin_transaction{
     if(something) break; //(1)
   }retry{
     if(stop_trying) break; //(2)
   }end_retry_in_loop;
}

possibilities:
a) keep the current behaviour, (2) does not break the user loop, but  
the internal one
b) make (2) break the user loop
c) prohibit using control statements in retry{} clauses

I tend to b).
this would mean that the user has no easy way to stop retrying a  
transaction, but has to use c++ flow control for that, like exceptions  
or an own loop he can "break". but a) and c) would be pretty  
surprising to the user.

e.g., retrying max. 5 times:

try{
   begin_transaction{
     //...
   }retry{
     if(retries++ == 5) throw my_exc();
   }end_retry;
}catch(my_exc &e){
   //tx failed
}

on a related note, I think it should not be possible to rethrow from a  
retry{} clause:

begin_transaction{
   //...
}retry{
   throw; //error
};

the fact that an isolation_exception was caught is an implementation  
detail, so we should move the user's code on retry out of the catch{}  
block. (which is not a problem since the "break" above skips the part  
below of it anyway)

best,