[Libwebsockets] Event-Loop API

Andy Green andy at warmcat.com
Mon Sep 24 19:24:42 CEST 2018



On September 25, 2018 12:56:27 AM GMT+08:00, Brice Hamon <brice at ydotm.com> wrote:
>Nicolas,
>
>I have been using libwebsocket with an external event epoll loop for
>years
>now.
>It is quite straightforward and very stable.
>
>I have the libwebsocket running inside a thread from my framework. That
>thread has all the epolling mechanism build in.
>I use the lws xxx_POLL_FD callbacks (in the http[0] protocol) to add,
>modify and remove a file descriptor, like for a normal fd except that
>these
>fds are created by lws.
>
>The rest of the lws callback mechanism is working as it should, nothing
>special to do here.
>
>I hope it helps,
>
>Andy, I hope this won't be removed for V3.0 ? Thanks.

V3.0 has been around for some months... no I don't plan to get rid of external poll, but it's definitely not preferred compared with the event libs.  But if your 'event loop' is poll(), and you want everything, lws and your code, in one thread and one poll() wait, the external poll stuff is the simplest way to do it, although it's a bit clunky.

(A possible alternative now is use lws RAW sockets and file wsis for what was outside lws, then if everything is in lws using lws event loop, you can switch lws event loop implementation how you like.  But depending on what that external code is, it can be impractical to try to unify it.)

If you want epoll(), it's also supported by all the eventlib options... eg libuv has the advantage the poll backend is platform-specific and opaque, it chooses whatever works best on the platform.  If you were starting from scratch, unless you have a special reason to use epoll() directly I'd recommend libuv.  The eventlibs support multithreaded service as well, with an event loop per service thread.

-Andy

>Brice.


More information about the Libwebsockets mailing list