[Python-Dev] Proposed PEP on concurrent programming support (original) (raw)

PJ Eby pje at telecommunity.com
Wed Jan 4 06:07:27 CET 2012

On Tue, Jan 3, 2012 at 7:40 PM, Mike Meyer <mwm at mired.org> wrote:

STM is a relatively new technology being experimented with in newer languages, and in a number of 3rd party libraries (both Peak [#Peak] and Kamaelia [#Kamaelia] provide STM facilities).

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.

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.

The disadvantage is that any code in a transaction must be safe to run

multiple times. This forbids any kind of I/O.

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.

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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120104/fc0df923/attachment.html>

More information about the Python-Dev mailing list