Author pitrou
Recipients jcea, meador.inge, neologix, pitrou, rbcollins
Date 2012-01-03.17:29:28
SpamBayes Score 2.88141e-08
Marked as misclassified No
Message-id <1325611700.3356.3.camel@localhost.localdomain>
In-reply-to <1325611257.91.0.274440731606.issue13697@psf.upfronthosting.co.za>
Content
> 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)
History
Date User Action Args
2012-01-03 17:29:29pitrousetrecipients: + pitrou, jcea, rbcollins, meador.inge, neologix
2012-01-03 17:29:28pitroulinkissue13697 messages
2012-01-03 17:29:28pitroucreate