Charles-François Natali <neolo...@free.fr> added the comment: > Modifying an object which is already on a traditional queue can also > change what is received by the other thread (depending on timing). > So Queue.Queue's put() is not "atomic" either. Therefore I do not > believe this behaviour is a bug.
Agreed. > However the solution proposed is a good one since it fixes Issue > 10886. In addition it prevents arbitrary code being run in the > background thread by weakref callbacks or __del__ methods. Such > arbitrary code may cause inconsistent state in a forked process if > the fork happens while the queue's thread is running -- see issue > 6271. [...] > I would suggest closing this issue and letting Issue 10886 take it's > place. Makes sense. ---------- nosy: +neologix resolution: -> duplicate stage: test needed -> committed/rejected status: open -> closed superseder: -> Unhelpful backtrace for multiprocessing.Queue _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8037> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
