Closed zzzzwc closed 2 years ago
Each individual jp.Expr is not thread safe. The jp.Exprs are fairly light weight so the intent was that a new instance would be created if used in a different thread. There is a performance improvement by reusing the stack so the option for concurrent use should be to keep different instances of a jp.Expr for concurrent use. Maybe using a pool to reduce the use of Mutex and locking.
Maybe it is possible to have some kind of option to make jp.Expr thread safe versus not. I have to think about that.
Did you want to start a discussion on how this might become an option?
umm🤔,I haven't read the code of your repo completely, but only in the scenario mentioned by issue, I think that putting s.stack on the structure has relatively little performance improvement, and "jsonpath" is like A rule that will not change once it is confirmed, and adding this option will also increase the user's burden, so if I write it, I will make jsonpath thread-safe by default.
I'll do some benchmarks.
Finally got around to running the benchmarks. With some care there is not additional overhead in creating a new stack each time and that does make the scripts thread safe. I'll make that change. Thanks for not giving up.
Fixed in v1.12.12 which was just tagged and released.
Thank you for this library that allows me to import json data smoothly. But I still have a problem that when using jsonpath similar to [?(@.key0 == "value0")] to extract json data concurrently, it will operate jp.Script.stack concurrently. is it to save memory to put rhe "s.stack" on the structure? In order to enable concurrent access, is it possible to put "s.stack" on the stack?