Chaim Frenkel wrote:
> You are now biting off quite a bit.
What good is half a transaction? If transactions are to be useful,
they should be fully supported -- including rolling back stuff some
third party module did to its internal variables. (Maybe that's a
little extreme ;)
> I believe that this will increase the deadlock possibilities. Without
> a transaction, it might have been possible to get in and out of a subroutine
> without holding the lock except within the subroutine.
>
> With a transaction, all variables touched within the dynamic scope of the
> transaction will have to be locked.
Dead lock detection? Throw an exception and re-try the transaction?
I don't think there's any good answer for this. Joe Programmer must avoid
shooting himself in the foot. (BTW, if there's a possibility for deadlock
with a transaction, there's the possiblity of data corruption without
a transaction. I don't think transactions increase your exposure.)
Transactions are obviously going to be expensive and complicated, which
is why I suggested implementing them outside the core:
> KF> This type of language feature strikes me as something similar to the
> KF> Pascalish "with" proposal -- the "transaction" keyword triggers munging
> KF> of the variables used in the following block. Obviously the munging
> KF> is very different between these, but if we allow the general concept
> KF> of munging the intermediate code (parse tree or OP tree or whatever),
> KF> then both "with" and "transation" might be implemented from user code
> KF> outside the core.
That's not quite sufficient for full transactions either. We should also allow
user code to replace the assignment op in the virtual machine too. (And
whatever else Transactions.pm decides should be abortable.) Hmm. A transaction
could be a simple copy-on-write with an exception handler that just restored
all original values. That'd be efficient too because SVs can't move.
Somebody ;) should go through the more challenging RFCs and try to distill
out general features we could put in the internals to allow implementing
the RFCs outside the core. That way we wouldn't hold up Perl 6 while waiting
for a research project to finish.
- Ken
