[Libwebsockets] [PATCH] Let foreign loops setups to configure service threads ids

Andy Green andy at warmcat.com
Sun Feb 23 18:36:05 CET 2020

On February 23, 2020 5:21:03 PM GMT, Olivier Langlois <olivier at olivierlanglois.net> wrote:
>On Sun, 2020-02-23 at 16:42 +0000, Andy Green wrote:
>> > 3. New client connection binding to a specific service thread (this
>> > the feature that I use)
>> It's not illegal from lws perspective.  But obviously the moment you 
>> eg, want to proxy between those two client connections, it can't be
>> without locking.  So this can't be the supported way.
>What do you mean by proxying between the connections?
>I guess that any interactions between those 2 threads in the user code
>then becomes the responsability of the user code. It shouldn't be the
>burden of the library.

Normally lws is very good for various modes of buffering / translation / forwarding etc because from events related to one connection, you can directly use any lws apis on related connections, without locking and having to care if it's h1, h2, ws or whatever on either side, apart from handling the correct callbacks.  For example, lws supports h2 / h1 -> h1 proxying over tcp or unix domain soclet, raw proxying, and even ws proxying.... examples like the mirror protocol propogate tx between connected clients without locking... putting clients on separate threads kills pretty much all advanced usage including any muxed protocols.

>In my case, I have a very clear separation between the 2 clients so it
>is easy so far but the day they need to interact, I'll make sure that
>they are well-behaved multithread parties. I know what I am doing.

Sure.  Well, good luck.

>> > I mean if you suggest wrapping my new function around a
>> > directive such as:
>> > 
>> > #ifdef LWS_SMP_MAX > 1
>> > 
>> > as a compromise, that would be totally fine to me...
>> Yes if you have threads, what you're doing looks sane.  If you
>> lws, what you're doing falls to pieces as soon as you want h2, and h2
>> very much a supported lws feature.  So what you're doing can't be the
>> supported way, and the moment you want h2 you'll agree.
>I'll take your word for it. Idk h2 well enough to have an opinion on
>the topic. TBH, I haven't tackled with h2 at all yet. The day, I'll
>need it, I'll refactor my design and revert my position about
>multithread lws usage if required.


>I'm by far using everything lws has to offer. This is my build options:
>        -DLWS_UNIX_SOCK=ON \
>but the only unsupported mode as of now (according to lws main webpage)
>is client WS connection over H2.
>Is this on your todo list in a near horizon?

I personally don't have a use for it atm.  The main usecase crying out for ws-over-h2 is browser - server, that's supported already.


More information about the Libwebsockets mailing list