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.[[BR]]
 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.