RInChI 1.0 is not thread-safe.

[janholstjensen]

Current 1.0 release is not thread-safe. The API should be extended to allow multiple concurrent threads to use RInChI reliably.

[Artoria2e5]

I don't have clang-tidy here and my Internet is quite bad right now, so I am doing what I can with github code search (basically grep) and ctags. You might want to set up some Makefile for clang's static analyzers later.

Searched for "static". Found hit in src/lib/rinchi_logger.cpp. Can be thread-local, I think (no need for state/context struct and a bunch of API changes yet).

Found non-const globals in

• errors and result strings in src/rinchi_lib/rinchi_lib.cpp. Can also be thread-local, I think.
• cpp_error_message and cpp_input_buffer in src/rinchi_ora_cartridge/rinchi_ora_cartridge.cpp. No idea, I don't do Oracle DB.
• __latest_hash_cleartext in src/rinchi/rinchi_reaction.cpp. Test suite stuff, should be fine as-is? Also a test thing, _GlobalTestStats in src/lib/unit_test.cpp.
• InChI lib interface. Ugh.
  • inchi_lib_state in src/lib/inchi_generator.cpp. I don't buy this "must be a singleton" thing the comment says. At the very least each thread should get its own.
  • A bunch of function pointers plus inchi_lib_path, inchi_lib_path_c_str, inchi_lib_handle in src/lib/inchi_api_intf.cpp. Could make sense to add a lock so the library is only loaded once.
  • lib_inchi_errmsg when Windows in src/lib/inchi_api_intf.cpp. Should be thread-local, as GetLastError() is thread-local (kinda like errno).

[janholstjensen]

You have correctly located the places that need to change: It is the C interface that needs some work and the interface to the InChI library when it is loaded dynamically.
The "must be a singleton" comment was based on the assumption that it would be used single-threaded. In a multi-threaded context you are right - then it doesn't make sense.

The Oracle interface is written very much like the C interface. The default mode of loading external libraries into Oracle is by having each login session run a separate process that loads the library. The calls into the library are then effectively single-threaded - unless you explicitly configure the library to be loaded in free-threading mode.