[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libmicrohttpd] Re: Question on libmicrohttpd API

From: Christian Grothoff
Subject: [libmicrohttpd] Re: Question on libmicrohttpd API
Date: Wed, 15 Sep 2010 08:53:00 +0200
User-agent: KMail/1.13.5 (Linux/2.6.32-5-686; KDE/4.4.5; i686; ; )

On Wednesday 15 September 2010 07:59:28 you wrote:
> Hello.
> My employer asked me to add a special-purpose HTTP server to my
> application, and, to save my time, I am considering to use
> libmicrohttpd. The application is single-threaded and already uses a
> select-, poll- or level-triggered-epoll-based (depending on the
> platform) event loop, and thus is already designed as a set of callbacks
> that don't block. The expected load may be up to a thousand requests per
> second (the existing non-HTTP part of the application handles it
> easily).
> My question is whether it is possible to use the MHD_run (aka "no
> threads") model with the existing event loop that is based on poll or
> epoll, not on select. Well, I can always convert fd_sets from
> MHD_get_fdset() to something that other event loops expect, but this
> would negate the whole benefit of not passing the whole arrays of
> interesting file descriptors at least from epoll. Is there any way to do
> better - e.g., get notified about the changes in the sets of interesting
> file descriptors?

It is clearly NOT possible to do better with the *current* API.  However, I'm 
very open to suggestions for how to improve this and extend the API with an e-
poll friendly mechanism.  I'm aware that this may require some (moderate) 
internal changes as well, but I do think that it might be a good idea -- 
especially since with the right approach we might also eliminate the double-
select call (right now, using external select requires 2 select calls, one 
external call and then we call it internally again).

Happy hacking,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]