What kind of "thread safe" are deque's actually?

[Chris Angelico]

On Thu, 30 Mar 2023 at 07:36, Greg Ewing via Python-list
<python-list at python.org> wrote:
>
> On 30/03/23 6:13 am, Chris Angelico wrote:
> > I'm not sure what would happen in
> > a GIL-free world but most likely the lock on the input object would
> > still ensure thread safety.
>
> In a GIL-free world, I would not expect deque to hold a lock
> the entire time that something was iterating over it. That
> would require holding the lock as long as an iterator object
> existed referencing it, which could be a long time, even
> longer than the caller expects (no reference counting,
> remember!)

Certainly not, but I *would* expect the sorted() call to retain a lock
on the input object while it copies it (or, more precisely, for the
PySequence_List() call to do that).

> So for future-proofing I would recommend using deque's
> copy() method to copy it before doing anything that iterates
> over it. Hopefully that would be implemented in a thread-safe
> way (although the docs don't currently promise that).
>

Probably? It's actually less clear there, since a deque's copy method
is built on top of basic iteration and broadly looks like this (though
in C, not in Python):

def copy(self):
    ret = deque()
    ret.extend(self)
    return ret

Simplified, but mostly accurate. And extending is done by getting an
iterator, then repeatedly appending. So.... probably safe? Question
mark?

ChrisA