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

Andy Green andy at warmcat.com
Sun Feb 23 17:42:11 CET 2020

On 2/23/20 4:27 PM, Olivier Langlois wrote:
> 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?)

There's a minimal example available related to it, it's supported.

> 2. callback-on-writable (I don't care at all about this one)

Then let's no add an api related to it, but deprecate it.

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

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

> 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 ;-)

I'm not planning to remove the multi pts with LWS_SMP_MAX.  The foreign 
thread callback_on_writable stuff should start to go away by default... 
that will solve the callbacks you'te trying to hide by this proposed 
public api as a side effect and move us along at the same time.



More information about the Libwebsockets mailing list