Message150518
> 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) |
|
Date |
User |
Action |
Args |
2012-01-03 17:29:29 | pitrou | set | recipients:
+ pitrou, jcea, rbcollins, meador.inge, neologix |
2012-01-03 17:29:28 | pitrou | link | issue13697 messages |
2012-01-03 17:29:28 | pitrou | create | |
|