Re: [boost] [transact] code in sandbox

Subject: Re: [boost] [transact] code in sandbox
From: strasser_at_[hidden]
Date: 2010-02-12 03:46:34

Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:

>> why can't the user create his own try/catch block for that?:
>> (using your syntax)
>> BOOST_TRANSACT_ATOMIC(_) {
>>     try{
>>       ...
>>     }catch(my_exc &){
>>       _.commit();
>>     }
>> }BOOST_TRANSACT_COMMIT();
>
> Yes this is always possible. However, transactions and exception  
> handling are used for the same goal, recover from errors. Thus it is  
> interesting to handle them in the same way and in a single  
> try-cactch block.

why is this interesting?
if your goal is a language-like syntax, the user should not even have  
to be aware that the macro is implemented using a try/catch block. so  
why should he be able to add a catch-block? what's the advantage?

is this the only reason that you restart transaction objects instead  
of destructing and reconstructing them, or is there another?

from my viewpoint, it doesn't make sense to "restart" a transaction.  
when a transaction fails, you can repeat the operations in it in a new  
transaction. but there is no such thing as "restarting" it.

this would require considerable support from resource managers, so  
that each of them can reuse the transaction object for a new  
transaction.

>
>>>     _.force_to_abort();
>>
>> what does this do? retry the transaction but make sure it fails? why?
>> why don't you just go ahead and throw an exception that is not caught
>> inside the transaction scope?
>
> When the user wants to undo whatever the transacton block did, the  
> simple way is to abort the transaction. Don't forget that  
> transactions can be used in a single-threaded application to make  
> exception-safe code.

yes, but what's wrong with throwing an exception that is uncaught in  
the transaction scope?
undoing the transaction is the default behaviour when a transaction  
object is destructed.

> The question is what is the simple case. for an INNER transaction  
> Boost.STM provides a macro

snip

>
> #define BOOST_STM_USE_ATOMIC(TX)                                \
>     for (boost::stm::transaction TX;                            \
>             !   TX.committed()                                  \
>             &&  TX.restart();                                   \
>         TX.commit())
>

I was talking about "simple" from the user's perspective, not  
implementation-wise.
I'd also prefer a macro xxx{} instead of a combination of two macros  
xxx{}yyy(); but since this is not possible in all cases, it is better  
to provide only the latter imho.
providing another macro only to avoid writing yyy() in some  
cases(nested transactions) is confusing. you have to understand  
implementation details in order to decide if you can save yourself  
writing yyy().

>
> As I said in a preceding post, we can provide initialy both sets of  
> macros and see which set the users use more often.

yes, we can always do that. I'd still like to understand the benefit  
of the additional macros.
you have clearly spent more time than me on this topic and I'm looking  
forward to the paper, but right now I honestly don't see the benefit.
the benefit of the simple macro is 1) a less verbose interface, not  
having to write a loop each time, and 2) saving the user from the  
implementation details.

when the user needs to have control over code-on-retry etc., using the  
macros is not less verbose and the user has to be aware of the details  
that this is implemented as a loop and a try/catch block.
having more than one choice on which macro to use even adds complexity.