Replies: 3 comments
-
|
That sounds like a good improvement. Do you have the capacities to provide a solution/pull request? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Would be great to see a benchmark before this gets merged to ensure it doesn't hurt not-multithreaded environments |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@mdw00d are you able to provide a pull-request with the changes and perform some benchmark with your use case? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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.
Beta Was this translation helpful? Give feedback.
All reactions