[Libwebsockets] [PATCH] Let foreign loops setups to configure service threads ids
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
> 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
> the foreign thread callback-on-writable stuff has not been documented
> used in the examples for a couple or years or more. Adding a public
> to stop it doing anything, mildly adding to the tid stuff, is less
> than actively starting to deprecate anything related to it, ie,
> this by adding a new option in cmake that's default off which
> any of the tid-related code for build.
> If it's a bit too indirect let me know and I'll have a go.
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
If you keep it, I promise to not try pushing my luck ;-)
More information about the Libwebsockets