| | 1 | Thoughts about how to implement dispatching |
| | 2 | |
| | 3 | ''Note: out of date; won't be refreshed until there's something more tangible planned out.'' |
| | 4 | |
| | 5 | * 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. |
| | 6 | * Users shouldn't have to implement complex event handling mechanisms in order to write a responsive, multiplexed application. |
| | 7 | * 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]] |
| | 8 | Options: |
| | 9 | 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. |
| | 10 | 2. Only threads calling ```basic_service<>::run()``` should handle requests, but the service should be able to increase the number of threads calling run(). |
| | 11 | 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. |
| | 12 | * 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. |
| | 13 | * When threading support isn't available, a FastCGI application (for instance) should still 'just work', with request handlers running concurrently instead of in parallel. |
| | 14 | |
| | 15 | '''Thread-pool vs. thread-per-request''' |
| | 16 | |
| | 17 | ''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.'' |
| | 18 | |
| | 19 | 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. |
| | 20 | |
| | 21 | '''Single-threaded application''' |
| | 22 | |
| | 23 | 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. |
