On Wed, 10 Feb 2021 at 16:49, László Böszörményi (GCS) <g...@debian.org> wrote:
> It was always a hack, few people used it and generated way too many messages.
It's a straightforward interface to indicate to the application when a
socket needs read/write. lws might not like it, but it's simple and it
works fine.
> Indeed, Andy provides at least two options for that: libev (full
> featured and high-performance event loop) and libuv (which is an
> asynchronous library, also used for Node.js). Meaning both are common
> and tested.
libev isn't cross platform.
libevent is lower performance.
libuv is great, but lws uses the libuv interface they explicitly say
to avoid if you want scalability. I've tested it out, it's not good
enough. Also, libuv doesn't play nicely with TLS. It's the one thing
I'd like to move to, but I can't do that with the drop in performance.
glib is a big dependency which would be unacceptable on some platforms
where mosquitto sees a lot of use.
> But as I know, websockets is a second class citizen in mosquitto [2].
That comment only applies to the listening sockets, it's irrelevant to
the external poll support which applies to the client sockets.
> My question is what functional difference will be in mosquitto without
> the websocket external poll support? I'm not sure it will not hit
> other websocket users.
Without external poll support, the listening sockets will operate
exactly as before, because they don't rely on the external poll
support. Clients will be able to connect... but then the server will
never be able to receive data from them, nor send anything to them.
The below code is the entirety of what would be added if you enable
external poll support, taken from the few different functions they
live in. 27 lines of code, that's it. All of the calls are essentially
the same - if we have a vhost, call the callback and if it fails then
return -1. The callback is the same that all applications must already
be using, and they should already be ignoring callback events that
they don't directly handle or they would get errors already.
Which part of this is hacky?
if (wsi->a.vhost &&
wsi->a.vhost->protocols[0].callback(wsi,
LWS_CALLBACK_CHANGE_MODE_POLL_FD, wsi->user_space, (void *)pa, 0)) {
ret = -1;
goto bail;
}
if (wsi->a.vhost &&
wsi->a.vhost->protocols[0].callback(wsi,
LWS_CALLBACK_LOCK_POLL, wsi->user_space, (void *) &pa, 1))
return -1;
pa.events = pt->fds[pt->fds_count].events;
if (wsi->a.vhost &&
wsi->a.vhost->protocols[0].callback(wsi,
LWS_CALLBACK_UNLOCK_POLL, wsi->user_space, (void *)&pa, 1))
ret = -1;
if (wsi->a.vhost && wsi->a.vhost->protocols &&
wsi->a.vhost->protocols[0].callback(wsi,
LWS_CALLBACK_LOCK_POLL, wsi->user_space, (void *)&pa, 1))
return -1;
if (lws_socket_is_valid(wsi->desc.sockfd) && wsi->a.vhost &&
wsi->a.vhost->protocols[0].callback(wsi,
LWS_CALLBACK_DEL_POLL_FD, wsi->user_space, (void *) &pa, 0))
ret = -1;
if (wsi->a.vhost &&
wsi->a.vhost->protocols[0].callback(wsi,
LWS_CALLBACK_UNLOCK_POLL, wsi->user_space, (void *) &pa, 1))
ret = -1;
if (wsi->a.vhost &&
wsi->a.vhost->protocols[0].callback(wsi,
LWS_CALLBACK_LOCK_POLL, wsi->user_space, (void *) &pa, 0))
return -1;
if (wsi->a.vhost &&
wsi->a.vhost->protocols[0].callback(wsi,
LWS_CALLBACK_UNLOCK_POLL, wsi->user_space, (void *) &pa, 0))
ret = -1;
> You had two years (maybe more) to switch to a better alternative of
> the hacky external poll support but only now realize your code is not
> complete without it. :(
I just fundamentally disagree that it's a hacky solution, and I don't
see how anybody could say that it is. There is no better performing
option in libwebsockets that allows cross platform support, with the
possible exception of glib. The packages I provide outside of distros
don't have the problem because they use external poll support. I'm now
trying to fix that here.
