Antoine Pitrou <pit...@free.fr> added the comment: > Note that another solution would be to use a dedicated thread for > signal management (like Java does), but that's another story.
That sounds like a good solution in the middle-term. Are there any drawbacks? (apart from launching a thread) > Also, this shouldn't be a problem for the buffered I/O code, since the > code already accounts for this possibility (if the lock is already > acquired by the current thread, an exception is raised). Yes, but raising an exception is less helpful than doing what the user asked for :) > Now, there's something I don't understand: I've just had a quick look, > but AFAICT, there's no reason why the C version of RLock could not be > available: am I missing something? Why do we even have a Python > implementation? The C version is quite recent, and there's a school of thought that we should always provide fallback Python implementations. (also, arguably a Python implementation makes things easier to prototype, although I don't think it's the case for an RLock) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13697> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
