[Python-ideas] Fwd: Concurrent safety?

[Mike Meyer]

On Tue, Nov 1, 2011 at 9:36 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 1 November 2011 15:38, Mike Meyer <mwm at mired.org> wrote:
> > No, the proposal does make things "safe by default". The default behavior
> > disallows all mutation. You have to do something explicit to allow it -
> > because "explicit is better than implicit."
> [...]
> > Um, yeah, I did point out  later in the paragraph that preserving pythons
> > data types may make this assumption false.
> [...]
> > And I also pointed out that this may be to much of a change to be
> palatable
> > to Python users. For that matter, if it requires losing pythons primitive
> > container types, it's probably to much of a change to be palatable to me.
>
> I don't know if you've considered this already, but a for-loop in
> Python creates an iterator and then mutates it (by calling next()) on
> each run through the loop. I can't see any way this could be a
> concurrency problem in itself, but you'd likely need to either
> reimplement the for loop to avoid relying on mutable iterators, or
> you'd need to add some sort of exclusion for iterators in for loops.


How about a third option? Iterators have to be locked to do a next in
general, as they can be bound and thus shared between execution threads. On
the other hand, locking & unlocking should be the major performance hit, so
you don't want to do that on something that's going to be happening a lot,
so the caller should be allowed to do something to indicate that it's not
required. Locking the iterator should do that. So the next method needs to
add a test to see if self is locked, and if not lock and then unlock self.

It'll be details like this that will be the hardest to thrash out, I
> suspect...


Yup.

    Thanks,
    <mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111101/a0b5d9b9/attachment.html>