Boost logo

Boost :

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)
>> try{
>> ...
>> }catch(my_exc &){
>> _.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

>>> _.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


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

I was talking about "simple" from the user's perspective, not
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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at