Re: [libmicrohttpd] Thread Pooling

[Christian Grothoff]

On Wednesday 04 March 2009 05:46:44 pm Richard Alimi wrote:
> Hi All,
>
> First of all, thank you for a wonderful library! We're currently using this
> in our implementation of P4P, which is a way for ISPs to provide network
> information to help applications optimize network usage (e.g., peer
> selection in BitTorrent).

Thanks.  Is this free software that we could link to from the MHD webpage?

> You can probably imagine in this use case that we need the ability to scale
> to a large number of users.  Thus, I'm quite interested in the epoll()
> enhancement that has been proposed.  I've currently got a patch (currently
> against SVN Revision 7728) to implement thread pooling. It basically
> operates by spawning a fixed (configurable) number of threads at startup,
> and each thread handles a single connection at a time.  Thus, it is
> basically THREAD_PER_CONNECTION mode without the overhead of spawning new
> threads upon accepting a new connection.
>
> Ideally, this would be extended to be able to spawn multiple threads, and
> within each thread use select() (or epoll()) to handle multiple connections
> simultaneously.
>
> So, there are basically two questions:
>
> 1) Is there interest in merging a patch for the current thread pooling
> implementation?  If so, I'll be more than happy to clean it up, update to
> the current SVN revision, and submit.
>
> 2) Is there interest in extending it to support multiple connections within
> each thread? If so, I can see about additionally implementing this
> behavior.

I'd say that would be interesting, especially if either
1) the needed growth in the code base is really small or
2) support to disable the feature using configure is present

Note that it is not quite enough to just have a patch against src/daemon/, I'd 
like to also see reasonable test cases for the new feature in testcurl/ so 
that we can ascertain that it works on the various platforms. 

Overall, I'd certainly say thread-pool + select/epoll-per-thread (as well as a 
pure epoll/kqueue model) would all be great to have; however, doing the work 
load balancing between the different threads might require some tricky code.  
So in my book the quality (== simplicity) of the code and its test cases is 
really the only question that I'd raise before applying such a patch.

My 2 cents

Christian