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

Olivier Langlois olivier at olivierlanglois.net
Sun Feb 23 17:27:18 CET 2020

On Sun, 2020-02-23 at 16:09 +0000, Andy Green wrote:
> On 2/23/20 3:56 PM, Olivier Langlois wrote:
> > Hi Andy,
> > 
> > In my use case, I'm definitely not trying to call
> > lws_callback_on_writable() from a different thread.
> > 
> > I use the service_tid to bind a newly created client connection to
> > the
> > service thread that created it. This is done inside
> > lws_client_connect_via_info().
> > 
> > service_tid is set by code found in plat. ie: unix-service.c
> > You are out of luck if your are using a foreign loop because then
> > the
> > service_tid is never assigned.
> Right... but if you use a foreign loop, it shouldn't be using the
> only 
> thing I know cares about the tid... if it's just the mysterious 
> callbacks coming and nothing breaks then I get it.

This correct. Unexplained callbacks and nothing else. All is good.
> > This is why I need this patch. Simply to make the code orthogonal
> > and
> > behave identically whether you use the internal poll or a foreign
> > loop
> > in relation with the service_tid assignation.
> Yes it's not doing something wrong but the tid stuff is on its way
> out, 
> the foreign thread callback-on-writable stuff has not been documented
> or 
> used in the examples for a couple or years or more.  Adding a public
> api 
> to stop it doing anything, mildly adding to the tid stuff, is less
> good 
> than actively starting to deprecate anything related to it, ie,
> solve 
> this by adding a new option in cmake that's default off which
> enables 
> any of the tid-related code for build.
> If it's a bit too indirect  let me know and I'll have a go.
> -Andy
My understanding is that there is 3 use-cases for multithread:

1. Concurrent load-balancing multithreaded server. (This one is rock
solid and well-documented, right?)
2. callback-on-writable (I don't care at all about this one)
3. New client connection binding to a specific service thread (this is
the feature that I use)

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...

but I fully understand your dilema about keeping this stuff... Keeping
it is inviting requests to something that you don't feel like it should
be in.

If you keep it, I promise to not try pushing my luck ;-)

More information about the Libwebsockets mailing list