homepage

> _pending_free uses a lock internally to make it thread-safe, so I
> think this will have exactly the same problem
You are probably right. Can't we use a lock-less list? list.append is
atomic thanks to the GIL, isn't it? But I don't know how to implement
the lock-less list consumer. It would be nice to have a function to
remove and return the content of the list, an atomic "content=mylist[:];
del mylist[:]" function.
> (the trylock can fail in case of contention or free() from multiple
> threads, thus we can't be
> sure that the else clause is executed on behalf of the garbage
> collector and it won't run while we're adding the block to
> _pending_free)
If two threads call free at same time, the "second" (taking the GIL)
will add the block to pending_free.
> Anyway, this seems complicated and error-prone, disabling the gc seems
> the most straightforward way to handle that.
I don't like touching such global "variable", but you are right.