[Libwebsockets] libev

Alejandro Mery amery at geeks.cl
Fri Dec 5 12:17:38 CET 2014


On Fri, Dec 05, 2014 at 07:20:05AM +0800, Andy Green wrote:
> 
> 
> On 5 December 2014 00:49:19 GMT+08:00, Alejandro Mery <amery at geeks.cl> wrote:
> >Hi,
> >
> >I need to integrate a libwebsocket client connection into an existing
> >ev_loop, but from what I see it the libev integration is still very
> >incomplete and just hacked in. so I need to finish it.
> 
> Great it was contributed, I guess that's all he needed.
> 
> >does it make sense to keep the polling hooks when using libev? maybe
> >implementing it as a separated plat instead of a ton of #ifdef-s? any
> >pointer on the preferred direction how I should approach it?
> 
> plat-blah is used to mop up differences like windows vs unix, the underlying technique is good though.
> 
> Something we need to take care about is a "distro build config" that makes it possible to use different options in one library binary, rather than rely on buildtime options for everything.  Because different apps using lws may have conflicting build-time requirements, but the distro will only ship one library built one way.
> 
> So a good mix would be yes, use event-libev.c, event-poll.c etc selectable at buildtime, but they would not be mutually exclusive, you could select a cmake to build in all of them.  Create an "ops" struct that defines function pointers for every job that can be done by the event implementations
> 
> struct lws_event_ops {
>      int (*lws_event_job1)(blah);
>      ...
> }
> 
> and each implementation file exports their ops like
> 
> struct lws_event_ops lws_event_ops_poll {
>     lws_event_job1_poll,
>     ....
> };
> 
> and in the info struct used to create the context, and the context itself we add a member
> 
> struct lws_event_ops *event_ops;
> 
> if NULL in info at context creation time, it's set to lws_event_ops_poll by default.  If the app wants to specify the event system to use, he sets the member in info to one of the exported ops structs from the event implementation files.
> 
> When some come needs to get the event implementation to do something, he calls like
> 
> context->event_ops->lws_event_job1(...);
> 
> Does it sound reasonable?

in principle yes, but for example the mapping between fd and swi
(connection manager?) is most likely also handled by the same module.
should I do a different lws_foo_ops for those?

considering most structs are opaque, does it make sense to
export a function to "initialize" the &info from within event-foo.o ?
the initialization for each event module is very likely to need
different things.

also, how to include the fields needed by each in context and wsi? a
union of specialized structs or following the current approach of
adding more direct fields? (same question for &info)

cheers,
Alejandro Mery



More information about the Libwebsockets mailing list