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:- 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.
- Only threads calling
basic_service<>::run()
should handle requests, but the service should be able to increase the number of threads calling run().
- 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.
- There should be threads calling
- 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.