Improvements to ProcessRequestThread pool handling in the MainServer of MythBackend

[Russell Bryant <russell@…>]

The attached patch provides some improvements to the handling of the request processing thread pool in the MainServer? of MythBackend?.

• In the ProcessRequestThread? class, both the setup() and killit() functions unlocked the mutex before signalling the wait condition. The patch moves the unlock to be *after* the condition is signalled, to remove the possibility of a race condition between the thread waiting on the condition and the thread signaling the condition.

• The rest of the changes rework the way a thread is acquired from the thread pool. I will explain the previous behavior, as well as the behavior after the patch.

Previous Behavior

The code created a timer and checked the container of idle threads once every millisecond, locking and unlocking the mutex each time, until a thread was acquired. If a thread was not acquired after a total of 10 ms, it would create a new one.

When creating a new thread, the code would wait 50 ms to attempt to ensure that the new thread is up and running before continuing.

New behavior

The code attempts to retrieve a thread from the thread pool. If one is not available, it uses a thread condition to wait for up to 10 ms until one becomes available. When threads become available, this condition is signaled to wake up anyone waiting on an idle thread.

Also, when a ProcessRequestThread? is created, it uses a thread condition to wait for the thread to be up and running. This both ensures that the code does wait long enough, and also doesn't wait any longer than it needs to.

Also, in the MainServer? constructor, it now uses this thread condition to ensure that each thread created for the thread pool is running before moving on. Previously, this check was not done here.

[stuarta]

(In [13825]) Closes #3517. Various improvements to thread pool handling from Russell Bryant

See the ticket for all the gory details