[Libwebsockets] client protocol selection criteria discussion

Olivier Langlois olivier at olivierlanglois.net
Sun Feb 23 17:08:46 CET 2020

On Sun, 2020-02-23 at 07:55 +0000, Andy Green wrote:
> The code doing that is a good example of why I stopped trying to make
> people happy by supporting these threaded usecases ad-hoc without a
> solid plan (ie, a solid plan is lws_cancel_service() being definitely
> threadsafe under all conditions and for all event libs by virtue of
> pipe()).
> This code is coming from an earlier attempt to make
> lws_callback_on_writable() the api threads could use to interact with
> the lws event loop.  The idea was if you have multiple threads, you
> should handle GET_THREAD_ID in protocols[0] and return with your
> platform thread id (tid != tsi... tid is like the pthreads tid or
> whatever).  Then, lws_callback_on_writable() can refer to this to
> find out if it's being called from a different thread than the lws
> event loop.
Just as a sidenote. You aren't supposed typecast pthread_t into an int.
In practice, it works well on Linux because pthread_t maps to a long by
the pthread lib even provide a function (more likely just a macro)
called pthread_equals() to compare ids together.

Maybe I went too literal with that but in my GET_THREAD_ID
implementation, I maintain an array of pthread_t and I search for the
array index for which pthread_equals(pthread_self(),arr[i]) returns

lws multithread support works super well as-is. Note, that I never
asked you to change anything to it. I looked what was offered by lws
and found out a way to use it that fit my needs. IMHO, that is your call to keep multithread support minimal but what is currently here works well. you should keep it.


More information about the Libwebsockets mailing list