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
Uh oh!
There was an error while loading. Please reload this page.
-
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