On 03/29/2012 04:48 PM, R. David Murray wrote:
On Thu, 29 Mar 2012 16:31:03 -0400, "R. David Murray"<rdmur...@bitdance.com>
wrote:
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum<gu...@python.org> wrote:
My original assessment was that this only affects dicts whose keys
have a user-implemented __hash__ or __eq__ implementation, and that
the number of apps that use this *and* assume the threadsafe property
would be pretty small. This is just intuition, I don't have hard
facts. But I do want to stress that not all dict lookups automatically
become thread-unsafe, only those that need to run user code as part of
the key lookup.
You are probably correct, but the thing is that one still has to do the
code audit to be sure...and then make sure that no one later introduces
such an object type as a dict key.
I just did a quick grep on our project. We are only defining __eq__
and __hash__ a couple places, but both are objects that could easily get
used as dict keys (there is a good chance that's *why* those methods are
defined) accessed by more than one thread. I haven't done the audit to
find out :)
The libraries we depend on have many more definitions of __eq__ and
__hash__, and we'd have to check them too. (Including SQLAlchemy,
and I wouldn't want that job.)
So our intuition that this is not common may be wrong.
--David
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/animelovin%40gmail.com
Hm, as far I understand this seems like an issue for gnu PTH, not python
job, which should transparently handles thread safety
issues based on the host/machine capabilities. Therefore I hope the fix
in python don't affect thread-unsafe apps to raise spurious
RuntimeErrors when a dict get modified across a SMP-aware platform... :-)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
