Re: [Buildroot] R: [PATCH 1/1] package/libwebsockets: added option to (re-)enable external poll loop support

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Luca, All,

On 2023-05-22 06:34 +0000, Pesce Luca via buildroot spake thusly:
> > Da: Yann E. MORIN <yann.morin.1998@free.fr>
> >On 2023-05-19 16:45 +0200, Luca Pesce via buildroot spake thusly:
> >> Since version 3.2.0, libwebsockets does not compile its external loop support
> >> code anymore. That code was put under LWS_WITH_EXTERNAL_POLL compile option,
> >> which defaults to OFF.
> >> Applications relying on that support need to turn that option on, so let's
> >> add it to the package.
> >So, as I understand it, before 3.2.0, this was unconditionally compiled
> >in, right?
> > If so, for backward compatibility, should we default this new option to
> > 'y' ?
> Well, it is not clear to me why in libwebsockets >= 3.2.0 the new option defaults
> to OFF, but it is hinting to something not so broadly used - the comment
> of the commit which introduced that change says something:
> https://github.com/warmcat/libwebsockets/commit/d3021980194991d175388115a65a4265bd155f36
> 
> So, I would say that the default should be n, and then let users enable it only if needed.
> Maybe the help text in the Config.in may remind that this support was unconditionally
> compiled in for version < 3.2.0.

Our policy is not to change the default behaviour if at all possible, so
I think this new symbol should default to 'y' (with a comment that
states "legacy"):

    default y  # legacy, was previously always enabled

> >> For example, when libwebsockets in enabled, mosquitto broker is built with
> >> websocket support, but its code requires LWS_WITH_EXTERNAL_POLL to be on -
> >> otherwise, it gives compile-time warning hinting to unusable websocket support:
> >>Then, should mosquitto also select this new option?
> It could, yes. It is not a compile-time requirement, but rather a run-time one.

Then yes, mosquitto should select it (otherwise there is a performance
regression).

[--SNIP--]
> >> +     help
> >> +       Enable external poll loop support code.
> > I am not sure I understood this "external poll loop support". Does it
> > mean that the loop must be handle by the application itself, rather than
> > bey libwebsocket?
> The library can be run on either its own internal loop (default behaviour) or
> by having its fds incorporated on an external one (so, the application own loop),
> using an application-provided callback. The latter is now under the
> aforementioned cmake option (see the cited commit above).

ACK, thansks for the clarification.

Will you submit an updated patch (default to y, and select from
mosquitto) ?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot