The PI-API library is NOT reentrant. All calls are handled in a synchronous manner. Once a function call is made, the calling program is typically blocked until the function returns. Because the library is not reentrant, programmers must refrain from creating multiple concurrent execution paths in their code that share PI-API connections to the server.
Under 16-bit Windows, two programs that use the same DLL share code and data. For this reason programs that load the same PI-API DLL should not be run concurrently. To avoid this problem, OSI client products each have their own externally and internally named DLLs that contain the same PI-API code (e.g., piapiad.dll, piapipb.dll). The library named piapi.dll distributed with this software is for use by third party PI-API programs. More than one of these programs must not be run at a time on a single machine.
Under 32-bit Windows environments (Windows 9x, WindowsNT, Alpha NT), each process that loads a DLL has the DLL mapped into its address space. DLL data is not typically shared in this environment and the PI-API is no exception. This means that multiple PI-API programs linked to the same DLL (piapi32.dll) can run concurrently. OSI client products and custom applications all use the same DLL. These platforms also support multiple threads of execution within a process. When writing threaded applications, calling the PI-API from multiple threads within a process should be avoided.
The UNIX environments are similar to 32-bit Windows. The PIAPI library is either linked into the application (statically linked archive library) or mapped into each process's address space (shared libraries). The same threading restrictions apply. In addition, forking child processes that share connection information is not supported. For example, opening a connection to a server in a parent process, and then forking and using this connection in the parent and resulting child process, is not supported.