implements() not thread-safe?
Matt Good
to modify the class declaration where they're used and someone
mentioned that using a global to handle this is not thread-safe,
unlike the frame-inspection method formerly used by Trac:
http://groups.google.com/group/sqlelixir/browse_thread/thread/1fb0b9512ad29fd1/a2d4e5ae55e11104?#a2d4e5ae55e11104
This is where Trac's implementation was changed: http://
trac.edgewall.org/changeset/3729
I don't know of any problems that have actually occurred because of
this, but if there's a chance this could happen, I guess it's better
to be safe.
-- Matt Good
Christian Boos
> ...
It don't think it's thread-safe, but at the same time the concurrent
operations involved on that global are very simple ones, so an
interference is very unlikely to happen.
I think there's a more fundamental issue with the component
architecture, though, it's the impossibility to provide a default
implementation for methods, which translates to numerous kludges in the
code base.
I remember Christopher saying (in [1]):
> About providing default implementations of interface methods:
interfaces are (intentionally) orthogonal to
> inheritance…
... but I fail to see the reason why this is an advantage.
For example, Pocoo has a component architecture based on multiple
inheritance [2] and it seems to be at the same time simpler and more
powerful than what we currently have (not to mention thread-safe and
without frame hacking ;-) ).
-- Christian
[1] - http://trac.edgewall.org/ticket/3655#comment:7
[2] - http://trac.pocoo.org/browser/pocoo/trunk/pocoo/__init__.py
Christopher Lenz
Good point. The inner class example is pretty convincing, regardless
of whether there's a thread-safety problem lurking here. I'd be okay
switching back to the frame hacking.
BTW, the idea for the change in r3729 was based on comments on
<http://blog.ianbicking.org/more-on-python-metaprogramming.html>.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/