[Top][All Lists]

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

Re: [libmicrohttpd] Re: Question on libmicrohttpd API

From: Simon Newton
Subject: Re: [libmicrohttpd] Re: Question on libmicrohttpd API
Date: Wed, 15 Sep 2010 07:52:28 -0700

On Tue, Sep 14, 2010 at 11:53 PM, Christian Grothoff
<address@hidden> wrote:
> 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).

+1 on this. I have the same problem. A callback which is run when the
state changes for a fd would be really useful.

> Happy hacking,
> Christian

reply via email to

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