On Wed, 4 Jan 2012 00:07:27 -0500
PJ Eby <p...@telecommunity.com> wrote:
> On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer <m...@mired.org> wrote:
> > A suite is marked
> > as a `transaction`, and then when an unlocked object is modified,
> > instead of indicating an error, a locked copy of it is created to be
> > used through the rest of the transaction. If any of the originals
> > are modified during the execution of the suite, the suite is rerun
> > from the beginning. If it completes, the locked copies are copied
> > back to the originals in an atomic manner.
> I'm not sure if "locked" is really the right word here. A private
> copy isn't "locked" because it's not shared.
Do you have a suggestion for a better word? Maybe the "safe" state
used elsewhere?
> > For
> > instance, combining STM with explicit locking would allow explicit
> > locking when IO was required,
> I don't think this idea makes any sense, since STM's don't really
> "lock", and to control I/O in an STM system you just STM-ize the
> queues. (Generally speaking.)
I thought about that. I couldn't convince myself that STM by itself
sufficient. If you need to make irreversible changes to the state of
an object, you can't use STM, so what do you use? Can every such
situation be handled by creating "safe" values then using an STM to
update them?
<mike
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
