Thoughts about how to implement dispatching

Note: out of date; won't be refreshed until there's something more tangible planned out.

• 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.
• Users shouldn't have to implement complex event handling mechanisms in order to write a responsive, multiplexed application.
• 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.
  Options:
  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.
  2. Only threads calling basic_service<>::run() should handle requests, but the service should be able to increase the number of threads calling run().
  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.
• 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.
• When threading support isn't available, a FastCGI application (for instance) should still 'just work', with request handlers running concurrently instead of in parallel.

Thread-pool vs. thread-per-request

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.

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.

Single-threaded application

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.