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

Olivier Langlois olivier at olivierlanglois.net
Sun Feb 23 18:21:03 CET 2020

On Sun, 2020-02-23 at 16:42 +0000, Andy Green wrote:
> > 3. New client connection binding to a specific service thread (this is
> > 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 done 
> 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.

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.
> > I mean if you suggest wrapping my new function around a preprocessor
> > 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 maintain 
> lws, what you're doing falls to pieces as soon as you want h2, and h2 is 
> 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?

More information about the Libwebsockets mailing list