The HttpCmdThreadPool class is considered as being part of the advanced Barracuda API.
The web-server runs in the context of the thread running the SoDisp when the web-server delegates a request to a resource such as a CSP page or a resource collection such as HttpResRdr. The web-server directly calls the resource service function in single thread mode, and no other requests can be serviced as long as the resource service function is running. In other words, other clients will have to wait for the current client to complete his request. This is usually not a problem since a service function is typically very fast.
Sometimes it is not possible to make a service function execute fast:
One reason for a lengthy response may be that the user is uploading a very large file and has a slow dial up connection. Another reason might be that the resource service function must wait for another thread to complete a lengthy calculation -- i.e. the service function is waiting on a message box, semaphore, etc..
For example, if using the HttpResMgr class as a file manager, downloading large files may take considerable time. A single threaded web-server running the HttpResMgr service function will block all other requests until the download is completed. Please note that this is only the case for downloading files and not for uploading files to the server.
The web-server is not directly calling the resource service function when delegating a request when using a HttpCmdThreadPool instance. The web-server is instead sending the request to the command thread pool. The pool then selects a thread from the pool and requests the thread to run the resource service function. This means that the web-server can immediately go back and wait for new client requests, while a thread in the thread pool runs the resource service function.
The web-server code is not reentrant and uses a mutex to protect the code. You initially create a mutex and pass the mutex to the SoDisp constructor. The dispatcher automatically locks the mutex before calling the web-server and releases the lock on return.
A thread in the thread pool uses the same mutex. The thread locks the mutex before calling the resource service function and releases the lock on return.
This means that any lengthy operation that runs within the web-server code that is not related to the web-server must unlock the mutex before starting the operation and set the mutex after the non-web server operation is completed.
C++ unlock example: