The query implementation currently uses pyparsing, which is known to not be thread-safe.
However, in order to use rdflib in a multithreaded environment, thread-safety is required.
A work-around is to monkey-patch the rdflib.Graph.query method with a method that wraps the call to the original rdflib.Graph.query call with a lock; however, it obviously would be preferred if the locking was handled natively, given this inherent weakness in pyparsing.
Quickly perusing the code, it appears rdflib/plugins/sparql/parser.py and rdflib/plugins/sparql/results/tsvresults.py are the two hot spots. Not sure if adding a lock in rdflib.Graph.query will catch all cases but it was sufficient for our purposes.
The query implementation currently uses pyparsing, which is known to not be thread-safe.
However, in order to use rdflib in a multithreaded environment, thread-safety is required.
A work-around is to monkey-patch the rdflib.Graph.query method with a method that wraps the call to the original rdflib.Graph.query call with a lock; however, it obviously would be preferred if the locking was handled natively, given this inherent weakness in pyparsing.
Quickly perusing the code, it appears rdflib/plugins/sparql/parser.py and rdflib/plugins/sparql/results/tsvresults.py are the two hot spots. Not sure if adding a lock in rdflib.Graph.query will catch all cases but it was sufficient for our purposes.