Subject: Re: [boost] [transact] code in sandbox
Date: 2010-02-12 08:17:42
Zitat von Vicente Botet Escriba <vicente.botet_at_[hidden]>:
> One try-catch block instead on two :)
has no advantage.
> On TBoost.STM the restat operation is less expensive than creating a
do you wish to change/extend the ResourceManager concept because of this?
in what way?
> Sometimes the user can not throw an exception because s/he is handling
> already an exception, on it is in a no throw function destructor, ... In
> these cases it will be more convenient to just state that the transaction
> could only abort.
ok. what does the call to transaction::commit() then do? throw? which
> This use is simple for the user perspective and efficient from the
> implementation point of view. I respect you wish to provide only a macro,
> but IMO there are more use cases than one on which macros could be used.
ok, my main point is that TRANSACT_ATOMIC/TRANSACT_COMMIT should be
not made more complicated in favor of more sophisticated use cases.
if there is a seperate set of macros, that's fine.
but if these should not be STM-specific but usable with Boost.Transact
in general, please describe what changes to the
TransactionManager/ResourceManager concepts and the basic_transaction
class you require for implementing the macros. (one of which would be
reusing transaction objects, as discussed above. what else?)
> With my macros or with yours, the user needs to be aware that the
> transaction block is included on a internal loop.
not necessarily. when you "return" from a transaction scope, commit()
isn't reached, so the transaction is not committed.
in this case:
}while(a++ == 5);
you don't expect that the side effects of the while-clause still takes
effect. so I don't see a problem in the behaviour that "return" omits
the commit either.
you could of course offer a macro like COMMIT_AND_RETURN.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk