Antoine Pitrou added the comment: I am not competent enough to pronounce on the technical detail of what you are proposing, but:
> Or maybe refactor to use condition variables in performance-critical code and > otherwise use kernel waits, if that makes sense. That can make sense IMHO. Lock and RLock are Python-facing objects, so I'm not sure using high-performance userspace primitives is really important there (after all, people will primarily suffer the evaluation cost of pure Python code so, unless you do something silly such as acquire and release a Python lock in a loop, the acquisition cost doesn't really matter). OTOH, the GIL may be more performance-critical (and needn't be interrupted), so can use userspace CV primitives. That will however entail a complication of the internal locking API, since we basically need two separate PyThread lock APIs: an "interruptible lock" API and a "fast lock" API. ---------- nosy: +tim.peters _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29971> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
