STINNER Victor <victor.stin...@haypocalc.com> added the comment: > _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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12352> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
