| | 69 | * In order for the program initialisation time (ie. the time before the first request begins to be handled) to be kept to a minimum, pre-emptive multithreading is not an option. |
| | 70 | * Users shouldn't have to implement complex event handling mechanisms in order to write a responsive, multiplexed application. |
| | 71 | * Since CGI request handlers can take a long time to complete, having i/o and request handling done in the same threads can cause starvation of i/o. Giving a guarantee that handlers will only be called in threads calling ```basic_service<>::run()``` might cause this and other problems.[[BR]] |
| | 72 | Options: |
| | 73 | 1. There should be threads calling ```basic_service<>::run()``` which handle input and output, and a separate set of threads which run the request handler provided by the user. |
| | 74 | 2. Only threads calling ```basic_service<>::run()``` should handle requests, but the service should be able to increase the number of threads calling run(). |
| | 75 | 3. If a user really wants all to be handled in the same threads, then passing a boost::thread_group to the service's constructor could provide a compromise: the user uses the thread_group to call ```basic_service<>::run()``` and the service uses it to dispatch request handlers. |
| | 76 | * As a consequence of the above points, the number of running threads should be variable. Without this would lead to unresponsive programs if the user wasn't using a Proactive (ie. asynchronous) model or didn't have a good way of monitoring the service and adapting the number of threads. |
| | 77 | * When threading support isn't available, a FastCGI application (for instance) should still 'just work', with request handlers running concurrently instead of in parallel. |
| | 79 | '''Thread-pool vs. thread-per-request''' |
| | 80 | |
| | 81 | ''Note: Since each connection can be multiplexing, it doesn't make sense to allow a thread-per-connection policy as this would make request response times inconsistent.'' |
| | 82 | |
| | 83 | In general a thread pool will be more efficient than having a thread per request, especially if the reply is no more than a true/false statement (eg. in the Authorizer FastCGI role). A thread-per-request option should exist since thread local storage would be compromised using a thread pooling strategy, making an application less secure. |
| | 84 | |
| | 85 | '''Single-threaded application''' |
| | 86 | |
| | 87 | In the case of threading support not being available, all services should still work. Also, the style of the first example (above) should map to a FastCGI application by simply creating an ```fcgi_service``` first and then passing that to the ```cgi::request```'s constructor. |
