Zitat von "vicente.botet" <vicente.botet@wanadoo.fr>:
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,