libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] Expose the fdset events


From: Simon Newton
Subject: Re: [libmicrohttpd] Expose the fdset events
Date: Tue, 2 Jun 2015 19:33:45 -0700

Digging up a thread from the past...

Is the codebase in a better shape to make this change now? We've run
into this again now that we've switched to using kevent rather than
select.


If you're looking for existing APIs to model this from,  Avahi has a
watch API [1] which provides fd notifications, and that has worked
well for us.

[1] http://avahi.org/download/doxygen/struct_avahi_poll.html


Simon


On Sun, Nov 25, 2012 at 11:42 AM, Simon Newton <address@hidden> wrote:
> On Sun, Nov 25, 2012 at 10:43 AM, Christian Grothoff
> <address@hidden> wrote:
>> On 11/25/2012 05:07 PM, Simon Newton wrote:
>>>
>>> I use microhttpd with the Open Lighting Architecture. As I've posted
>>> before we have a C++ wrapper around libmicrohttpd (HTTPServer), which
>>> then integrates with OLA's event management system.
>>>
>>> While this works, it's rather messy. The wrapper sets up a call to a
>>> HTTPServer::UpdateSockets() method into the event loop, and
>>> UpdateSockets() calls MHD_get_fdset to find out what FDs microhttpd is
>>> interested in.
>>>
>>> It then loops over all the FDSETs and tries to reconcile the event
>>> manager's state with the desired state from microhttpd. This involves
>>> adding and removing Socket objects from the event manager.
>>>
>>> I'd prefer it if I could set a callback to be run each time a FD
>>> should be added or removed from the event manager. Is that easy enough
>>> to do?
>>
>>
>> "Easy enough" is hard to say, what I can say is that it would not be
>> trivial.
>>
>> However, that doesn't mean it will never happen --- something similar would
>> be needed to make MHD work with epoll/kqueue-based event loops, which is in
>> general a nice system call that in a perfect world MHD should be able to
>> utilize.
>
> Yes, that's why I brought it up. The event manager started as a
> wrapper around select() but has grown more complex over time. I'm
> looking at changing it over to epoll.
>
>>
>> Nevertheless, the change would be quite invasive and would require work that
>> I won't be able to put in anytime soon.  So I guess what I'm saying is that,
>> while I'm not opposed, I don't see this happen anytime soon unless I
>> magically get a patch ;-).
>
> Ok, if I get some free time I'll have a go.
>
>>
>> Also, have you considered "improving" your event manager by extending its
>> interface to allow it to work also with fdsets directly?  Depending on the
>> system call that are you using internally in your event manager this might
>> be trivial.
>
> I'd have to have a way to associate callbacks with the fdsets, and
> then that starts to look a lot like the Descriptor objects we have
> now, only they'd have multiple fds associated with a single callback.
> Maybe it's worth adding, it's hard to say.
>
> Simon
>
>>
>> Happy hacking!
>>
>> Christian
>>
>>



reply via email to

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