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 the id() 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 = 5


class Test:
    
    def foo():
        global x
        x += 1
        self.cache = x

In [91]: t = Test()

In [93]: dis.dis(t.foo)
  8           0 LOAD_GLOBAL              0 (x)
              2 LOAD_CONST               1 (1)
              4 INPLACE_ADD
              6 STORE_GLOBAL             0 (x)

  9           8 LOAD_GLOBAL              0 (x)
             10 LOAD_GLOBAL              1 (self)
             12 STORE_ATTR               2 (cache)
             14 LOAD_CONST               0 (None)
             16 RETURN_VALUE

Should this just go into RendererBase.__hash__? (then get_prop_tup would just stick renderer into the tuple instead of id(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 different id 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 new id-conflicting renderer it would have the wrong uid. But something would have to be seriously 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 call next(_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 with https://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.