diff --git a/READMEs/README.coding.md b/READMEs/README.coding.md index 40de4a01..56d9645a 100644 --- a/READMEs/README.coding.md +++ b/READMEs/README.coding.md @@ -913,21 +913,35 @@ There is no knowledge or dependency in lws itself about pthreads. How the locking is implemented is entirely up to the user code. -@section libevuv Libev / Libuv support +@section libevuv libev / libuv / libevent support You can select either or both -DLWS_WITH_LIBEV=1 -DLWS_WITH_LIBUV=1 + -DLWS_WITH_LIBEVENT=1 at cmake configure-time. The user application may use one of the context init options flags LWS_SERVER_OPTION_LIBEV LWS_SERVER_OPTION_LIBUV + LWS_SERVER_OPTION_LIBEVENT -to indicate it will use either of the event libraries. +to indicate it will use one of the event libraries at runtime. +libev has some problems, its headers conflict with libevent, they both define +critical constants like EV_READ to different values. Attempts +to discuss clearing that up with libevent and libev did not get anywhere useful. + +In addition building anything with libev using gcc spews warnings, the +maintainer is aware of this for many years, and blames gcc. We worked +around this by disabling -Werror on the parts of lws that use libev. + +For these reasons and the response I got trying to raise these issues with +them, if you have a choice about event loop, I would gently encourage you +to avoid libev. Where lws uses an event loop itself, eg in lwsws, we use +libuv. @section extopts Extension option control from user code