On 11/07/2013 01:44 PM, Daniel Stenberg wrote:
> On Wed, 6 Nov 2013, Jakub Hrozek wrote:
>
>> Maybe you could also include libverto. It's relatively new event loop
>> library that encapsulates other event loop approaches as back ends.
>> It's being used by MIT Kerberos and GSS-Proxy among others.
>
> I would say that the most sensible thing for a library to do is to
> provide callbacks for what file descriptors to wait for (ADD, REMOVE,
> MODIFY) activities on, and what those activities are. And a separate one
> that sets a timeout timer if necessary.
>
> That should be possible to make work with any event library or select()
> / poll() or whatever out there.
>
> Not completely out of coincidense, that's the API libcurl provides for
> doing event-based operations...
I concur, a library should not bind itself to a specififc event handling
framework, especially because two different approaches in the same
application may be difficult to reconcile with each other.
But, since you mentioned timeouts, I start wondering whether it is such
a good idea to communicate only one single timeout. Doing so means you
have to maintain a priority queue of timeouts somewhere under the hood,
which is a complex thing. So, why not simply let the users know the
timeout for each fd, so they can put it in some priority queue (such as
the one provided by the event loop library) together with all the other
stuff that goes in there (one timeout queue per application).
This also lets the users make the design choices the library author does
not have enough information to make.
Best regards,
Alexander
Received on 2013-11-07