Author gvanrossum
Recipients JohanAR, davin, gvanrossum, itamarst, ncoghlan, pitrou, python-dev, rhettinger, sbt, serhiy.storchaka, tim.peters, yselivanov, zzzeek
Date 2017-08-18.21:26:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1503091613.09.0.382886788001.issue14976@psf.upfronthosting.co.za>
In-reply-to
Content
Given the date from that comment I assume that I told Raymond this during the 2016 core sprint. I can't recall that conversation but I am still pretty worried about using an RLock. (What if someone slightly more insane decides to call get() from inside a GC callback or signal handler?)

However I do think we have to do something here. It's also helpful that all mutable state except for unfinished_tasks is just a deque or list, and the _get()/_put() operations for these are atomic. (I betcha heappop() is too when implemented in C, but not when implemented in Python.)

I can't say I understand all of Antoine's patch, but it's probably okay to do it this way; however I would rather see if we can add _is_owned() to Lock, assuming it can be implemented using any of the threading/locking libraries we still support (I presume that's basically posix and Windows).

IIUC the end result would be a Queue whose put() works from signal handlers, GC callbacks and __del__, as long as it's unbounded, right? And when it *is* bounded, it will give a decent message if the queue is full and the lock is already taken, right? Antoine, can you confirm?
History
Date User Action Args
2017-08-18 21:26:53gvanrossumsetrecipients: + gvanrossum, tim.peters, rhettinger, ncoghlan, pitrou, zzzeek, python-dev, sbt, serhiy.storchaka, JohanAR, yselivanov, itamarst, davin
2017-08-18 21:26:53gvanrossumsetmessageid: <1503091613.09.0.382886788001.issue14976@psf.upfronthosting.co.za>
2017-08-18 21:26:53gvanrossumlinkissue14976 messages
2017-08-18 21:26:53gvanrossumcreate