[Python-ideas] Fwd: Concurrent safety?

Nick Coghlan ncoghlan at gmail.com
Thu Nov 3 05:48:56 CET 2011


On Thu, Nov 3, 2011 at 2:35 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Mike Meyer writes:
>  > managed to get the None-valued mock inserted in sys.modules due to
>  > a concurrency bug.
>
> I don't see your point.  You claim your proposal is supposed to help
> identify which objects are shared.  Taking that literally, this
> example is useless as an argument for your framework -- you already
> know which object is the problem.  Of course, I suppose you actually
> meant to get more precise information in cases like this, specifically
> about in what execution contexts the object is mutated.  But in this
> case, you probably already know precisely where in the code the
> offending mutation happens.  The bug is that execution of the
> framework code resumes "unexpectedly" before the "subordinate" thread
> restores the problem object's state to status quo ante.  Well, these
> are *threads*, so you can't say anything about when to expect them to
> resume, you have to expect resumption at any point.

This discussion is actually starting to sound a bit like the Python
security model discussions to me - ensuring that only certain kinds of
objects are reachable from a given point in the code, and controlling
the operations that can be performed on them.

Victor Stinner eventually managed to create his pysandbox module based
on those discussions, which does a fairly good job of locking things
down, even though I'd personally still be inclined to back it up with
additional OS level defences.

Still, like the GIL vs free threading discussions, there are unlimited
numbers of things that *could* be done, the question is what is
*worth* doing. And that's not going to be figured out in a mailing
list discussion - it's going to take real code and plenty of
experimentation, and it's going to have be done by people that don't
already believe the "right" answer is to use message queues and a "no
concurrent access to mutable objects" architecture at the application
level (i.e. where what threads buy you is the fact that you can hand
over an object just by putting the reference in a queue and dropping
yours, without any serialisation overhead).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



More information about the Python-ideas mailing list