Currently the attribute handler in src/attributes.c is defined as thread-local, which presents a problem when
a) an application using the igraph library is multi-threaded and different threads use different attribute handlers. In this case, graphs created in one thread are incompatible with graphs created in another. Pretty pathological case, but it is still a problem.
b) a Python application using the igraph library spawns a new thread and calls the Graph constructor from the new thread. Since the new thread does not have access to the Python attribute handler (and we cannot hook into the thread creation process to set the attribute handler there), the module crashes whenever an attempt is made to read the graph attributes.
There are two possible solutions that I can think of:
a) Make the attribute handler global again as it was in 0.5.x, and either protect it with mutexes (to maintain thread-safety) or add a big warning sign that asks the user to call it from the main thread only.
b) Add an extra pointer to igraph graphs that point to the attribute handlers they were created with. This would require some extra legwork when copying a graph because the copy has to inherit the same attribute handler. Probably not a big deal.
As for solutions, I obviously don't like b), because it is too much work for probably a small number of users. So I would vote for a).
In the first round, it might be enough to solve problem b), i.e. the problem with the Python interface. Plus we can document that people attaching attribute handlers in multithreaded programs should attach an attribute handler from each thread that is calling igraph functions. (Bad, but there are not too many people doing this, I believe.)