GProM has not been build with multi-threading in mind. We have global data structures all over the place and state in most places is only to be expected to exist one. Making libgprom thread-safe will be a longer term effort. The plan is as follows:
0) use mutexes to prevent concurrent access to libgprom functions
this is already implemented, but multiple threads/JDBC connections would still share the same state
1) encapsulate global state in data structs instead to group it
now new features, but this will be the first step towards multi-threading
2) change libgprom to be handle based
API change, but under the hood there will still be shared state for now
3) use one global handle. as a hack libgprom will switch the user handle for the global handle in every function invocation
this is a hack, but it avoids changes to every function and results in a simple concurrency control scheme
4) decide where to use mutexes and where to use handle passing
this would require quite some changes, but will result in a final, efficient multi-threading version of libgprom.
GProM has not been build with multi-threading in mind. We have global data structures all over the place and state in most places is only to be expected to exist one. Making libgprom thread-safe will be a longer term effort. The plan is as follows:
0) use mutexes to prevent concurrent access to libgprom functions