Huh, just realized that@tacaswell outlined basically this procedure in#7911 but I didn't recall it; must have been stuck in my subconscious somewhere.

I don't think this is thread safe, and that is ok. I do not think we make the claim that Matplotlib is threadsafe in any way. Further most of our time is spent in python and I do not think we release the GIL in the c extensions so it is not clear to me you would get any major gains (unless you really are I/O bound).

Although the way that this will fail to be thread safe also means both objects existing at the same time in which case theid() value should be different. If the race condition is between two threads calling_uid on the same renderer at the same time then the user is trying to render the same object on more than one thread and I expect other things to break.

x=5classTest:deffoo():globalxx+=1self.cache=x

In [91]:t=Test()In [93]:dis.dis(t.foo)80LOAD_GLOBAL0 (x)2LOAD_CONST1 (1)4INPLACE_ADD6STORE_GLOBAL0 (x)98LOAD_GLOBAL0 (x)10LOAD_GLOBAL1 (self)12STORE_ATTR2 (cache)14LOAD_CONST0 (None)16RETURN_VALUE

Should this just go intoRendererBase.__hash__? (thenget_prop_tup would just stickrenderer into the tuple instead ofid(renderer), renderer._uid.)

We probably do not want to go down the__hash__ route without implementing all of other__eq__ and friends methods.

For thread-safety, I was thinking more of subsequent renderers. Across the threads, the renderers would have differentid anyway, so it'd be fine if they ended up with the same value.

Theoretically, thread 1 could create a couple renderers in the time it takes thread 2 to store the wrong value. Then the next time thread 1 created a newid-conflicting renderer it would have the wronguid. But something would have to beseriously wrong with thread 2 if thread 1 was able to create multiple renderers in the time it took to load+add+store.

Actually you can just use itertools.count as a threadsafe counter (create _counter at the module level and callnext(_counter) to get a uid). Yes, this is only due to a CPython implementation detail (i.e. the GIL) but it's not worse than the current PR and should be at least as fast (or better) (in any case I doubt that's the slowest part of rendering).

That's a good idea; even if not thread-safe on all implementation, it's at least clearer.

@tomspur This patch should help withhttps://bugzilla.redhat.com/show_bug.cgi?id=1401267 (though leave out the pytest parts if on 1.5.3.)

thanks!

@QuLogic - great - thanks for doing that.