[prev in list] [next in list] [prev in thread] [next in thread]
List: python-list
Subject: Re: What kind of "thread safe" are deque's actually?
From: Chris Angelico <rosuav () gmail ! com>
Date: 2023-03-30 1:39:54
Message-ID: CAPTjJmr8=Gba892jxNX37utR9tF2sEy5MDgyYNaNGf+LAUX4vQ () mail ! gmail ! com
[Download RAW message or body]
On Thu, 30 Mar 2023 at 07:36, Greg Ewing via Python-list
<python-list@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
--
https://mail.python.org/mailman/listinfo/python-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic