The design of HLLAPI makes multithreaded programming very difficult. This is particularly problematic in the shared server environment such as found in IIS/ASP. This is due to a "process-wide" active session...if any thread connects to a specific session, that connection becomes the "active session" for the entire process.
Most first generation "server" implementations need to either run each request in a separate process or utilize a MUTEX semaphore controlling access and only allow a single thread at a time access the HLLAPI calls. When this is combined with the slow connect/disconnect common in traditional emulator environments, server performance is brought to a relative crawl making many organizations limit the number of sessions, even on powerful servers to under ten.
FlyHLLAPI, instead of maintaining a process-wide active connection, utilizes the Win32 thread memory services to maintain the active connections on a per-thread basis.
With FlyHLLAPI, the multithreading restriction is then avoided as long as each thread performs a connect to its session at the start of each transaction, and disconnects at the end of the transaction. This allows a pool of threads (used in the IIS architecture) to operate at top speed on hundreds of sessions concurrently.
