Thread safety of Informix 4GL

Answer

By design Informix 4GL is not currently thread-safe, and this has been the case since the very early versions. However with some limitations, it can still be linked to libraries that use multiple threads.

An important aspect is that you cannot run 4GL code on any other thread other than the main one. When a process that uses the pthread library is started, it runs just the main (initial) thread of execution exactly as in the case of a single-threaded sequential program. All the 4GL code must run on this main thread. You cannot create extra threads and run additional 4GL code on them as this would lead to an immediate memory corruption.

4GL internally uses non thread-safe calls such as setjmp()and longjmp() and sets signal handlers using signal() and timers using alarm(). The additional code shouldn't alter signals and timers set by 4GL as this may lead to unpredictable behavior in particular for specific responses to signals like SIGINT and SIGALRM when intercepted by other threads.

If you suspect the additional multi-threaded code linked to 4GL interferes with 4GL, consider a two process solution where the 4GL code runs on its own single-threaded process and interacts with the additional code, which runs as a second multi-threaded process via some form of inter-process communication such as pipes or sockets.

Note that in recent documentation you may find a reference to threads, in relation to 4GL being used to implement web services, at the page Simultaneous thread handling with FGLD daemon (product information).
The threads mentioned in this case are those running inside the AXIS2/C server and are not 4GL threads. The Informix 4GL daemon fgld was introduced exactly for the reasons explained earlier, allowing 4GL code for each request coming from AXIS to be run on a separate process.

Finally note that although scripts such as c4gl may link, among others, the pthread library to the executable, this doesn't imply anything about the thread safety of 4GL itself.