Message300532
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? |
|
Date |
User |
Action |
Args |
2017-08-18 21:26:53 | gvanrossum | set | recipients:
+ gvanrossum, tim.peters, rhettinger, ncoghlan, pitrou, zzzeek, python-dev, sbt, serhiy.storchaka, JohanAR, yselivanov, itamarst, davin |
2017-08-18 21:26:53 | gvanrossum | set | messageid: <1503091613.09.0.382886788001.issue14976@psf.upfronthosting.co.za> |
2017-08-18 21:26:53 | gvanrossum | link | issue14976 messages |
2017-08-18 21:26:53 | gvanrossum | create | |
|