[Libwebsockets] SMP: several protocol initialization

andy at warmcat.com andy at warmcat.com
Thu Apr 8 21:14:05 CEST 2021



On April 8, 2021 6:44:03 PM UTC, Mykola Stryebkov <mykola.stryebkov at icloud.com> wrote:
>Hi again :-)
>
>Let’s say I use SMP server with 5+ threads and 3 protocols.  I
>initialise protocol->id of those protocols to 1, 2 and 3. Having that,
>I expect to receive exactly 3 calls to my callback with
>LWS_CALLBACK_PROTOCOL_INIT reason and order of initialisation is not

You can arrange for that, without SMP.  But there are two separate issues there.

For backwards compatibility, without the explicit vhosts context info flag, all protocols given at context creation time are enabled on the default vhost.

But when you have a more complex situation with multiple vhosts, you have to name which protocols you want active on which vhosts by giving their names in a linked-list of pvos at vhost creation time.  Like this

https://libwebsockets.org/git/libwebsockets/tree/test-apps/test-server.c#n358

Otherwise you have no way to, eg, bind an internal protocol only to a vhost that listens on a unix domain socket, while offering a public protocol on an externally-reachable listen socket.

>important. Instead, in some cases (not always!) I receive:
>
>a) more than one init call for a protocol, like 1,1,2,2,3,3.
>Unpleasant, but not critical: bitmap + set of mutexes solve the issue.

I don't know why that's happening, it sounds like a missing smp adaptation bug.  Vhosts exist once and are listed once in the context, no matter how many pts.  Protocols are initialized once  per vhost; that's why vhd are referred to a vhost-protocol instantiations or private data.  You can pass the same protocol different pvos in each vhost, using the vhost's pvo with the matching protocol's child list.

But vhosts are children of the context.  The number of pts shouldn't change anything about that.

You'll have to get used to mutexes.  With smp you'll have to lock the vhd because it follows, all threads share the same vhd.

-Andy



More information about the Libwebsockets mailing list