<div class="gmail_quote">On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer <span dir="ltr"><<a href="mailto:mwm@mired.org">mwm@mired.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
STM is a relatively new technology being experimented with in newer<br>
languages, and in a number of 3rd party libraries (both Peak [#Peak]_<br>
and Kamaelia [#Kamaelia]_ provide STM facilities). </blockquote><div><br></div><div>I don't know about Kamaelia, but PEAK's STM (part of the Trellis event-driven library) is *not* an inter-thread concurrency solution: it's actually used to sort out the order of events in a co-operative multitasking scenario. So, it should not be considered evidence for the practicality of doing inter-thread co-ordination that way in pure Python.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A suite is marked<br>
as a `transaction`, and then when an unlocked object is modified,<br>
instead of indicating an error, a locked copy of it is created to be<br>
used through the rest of the transaction. If any of the originals are<br>
modified during the execution of the suite, the suite is rerun from<br>
the beginning. If it completes, the locked copies are copied back to<br>
the originals in an atomic manner.<br></blockquote><div><br></div><div>I'm not sure if "locked" is really the right word here. A private copy isn't "locked" because it's not shared.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The disadvantage is that any code in a transaction must be safe to run<br>
multiple times. This forbids any kind of I/O.<br></blockquote><div><br></div><div>More precisely, code in a transaction must be *reversible*, so it doesn't forbid any I/O that can be undone. If you can seek backward in an input file, for example, or delete queued output data, then it can still be done. Even I/O like re-drawing a screen can be made STM safe by making the redraw occur after a transaction that reads and empties a buffer written by other transactions.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For<br>
instance, combining STM with explicit locking would allow explicit<br>
locking when IO was required,</blockquote><div><br></div><div>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.)</div>
<div><br></div></div>