Using MT-Unsafe Libraries

This workaround is not trivial and may cause deadlocks if not carefully programmed. Do this only if absolutely unavoidable.

If you try to run a multithreaded Java application which also uses native C/C++ code that uses previously-released libraries which have not been compiled with the -D_REENTRANT flag on, there could be problems, as explained here.

With a native-threaded JVM such as 1.1, libc stores system call error code in a thread-specific errno. When an mt-unsafe library references errno, it references the global version, because it was not compiled with the -D_REENTRANT flag on. Therefore, the library can't access the thread-specific errno and its errno-dependent response to a failed system call would be incorrect.

The real solution is to ensure that an MT Java application that also uses native code by way of native methods is link with MT-safe (or at least errno--safe libraries).

However, if you cannot avoid referencing errno-unsafe libraries, the following workaround may help: Enable the main thread to enter the Java application and arrange for all calls to the unsafe library to be routed through the main thread. For example, if a thread makes a JNI call, the JVM can marshal all JNI arguments and put them in a queue serviced by the main thread. The thread can wait for the main thread to issue the call and return the results to it.

Note that it is not necessary for calls made from only the main thread to the unsafe library to go through a lock, since calls to the library are single-threaded through the library; only the main thread ever calls the library. The main thread could issue non-blocking calls, etc., to ensure some amount of concurrency. The main thread's errno is global, and the same errno would be referenced by both libc and the MT-unsafe library.