The strange limitation of 64 threads

When using the Windows I/O Completion Port (IOCP), people seem to limit their thread pools to a maximum of 64 threads.

This is probably caused by the fact that WaitForMultipleObjects limits the number of input handles with the nice magic constant MAXIMUM_WAIT_OBJECTS (which happens to be 64).

Here are a few examples:

• Creating a Thread Pool for MFC-Based ISAPI Extensions - this might be where it all started...
  
• The venerable IsapiThreadpool unit which originally appeared in Delphi 6. You only had to add it to your ISAPI DLL project to enjoy a nice performance boost.
• Many others...

The (anti-)pattern is related to the process of shutting down the thread pool: to do this cleanly, the threads in the pool should be allowed to finish what they're doing (or just wake up if they're idle at the moment), perform any cleaning up as necessary and terminate correctly. The shutdown is usually performed in two steps:

1. Send a shutdown signal (completion key) to each thread.
Each thread in the pool calls GetQueuedCompletionStatus in a loop and checks for the special (application-defined) shutdown completion key to which it responds by breaking out of the loop and terminating. The shutdown procedure can therefore simply send the shutdown completion key to the IOCP as many times as there are threads, relying on the fact that exactly one thread will respond to exactly one such signal.
2. Wait for all threads to terminate.
The shutdown is not complete before all threads actually had a chance to receive the signal and terminate. Only then it's safe to continue closing the IOCP, freeing memory, etc. So we absolutely have to wait for the threads to terminate. The reasoning here seems to be: Since WaitForMultipleObjects can only handle up to 64 threads, we can't allow more threads to be associated with the pool in the first place, can we?

Well, there's no need to use WaitForMultipleObjects in Step 2. It's fairly easy to keep a counter of active threads in the pool (interlocked-incremented when a thread starts, interlocked-decremented when a thread is finished). When the counter reaches zero (no more active threads), signal an event. With only one event to wait for, you can use WaitForSingleObject in Step 2.

Starting FPC compiler changed to 2.6.4

The starting FPC compiler (used to compile the latest trunk FPC) has been 2.6.2 for some time now. This has changed recently; to compile the latest trunk FPC you need FPC 2.6.4 which has not yet been pushed to official repositories. At the moment the easiest work-around is to upgrade to FPC 2.6.4 using Petr Hložek's PPA:

~ $ sudo add-apt-repository ppa:ok2cqr/lazarus
~ $ sudo apt-get update
~ $ sudo apt-get upgrade
~ $ sudo apt-get dist-upgrade

After the upgrade, your /etc/fpc.cfg is once more a symlink pointing to /etc/alternatives/fpc.cfg which itself is a symlink pointing to /etc/fpc-2.6.4.cfg. If you're following my previous notes you'll need to redirect /etc/fpc.cfg to your ~/Development/fpc.cfg again:

~/Development $ sudo rm /etc/fpc.cfg
~/Development $ sudo ln -s ~/Development/fpc.cfg /etc/fpc.cfg

FPC and Lazarus development environment (follow-up)

I've just done a fresh installation of Linux Mint 17.2 'Rafaela' MATE edition (64-bit) from scratch which went without a hitch. I've followed my previous notes to set up my FreePascal and Lazarus development environment, with success.