"Andy Green (林安廸)"
andy at warmcat.com
Wed Mar 27 15:07:01 CET 2013
On 27/03/13 21:57, the mail apparently from Michel Archambault included:
> Yes it's in another thread.
> My thread that received data from hardware is created on an hardware event and ends (almost) after I call libwebsocket_callback_on_writable_all_protocol().
> What you means by "it will blow up"?
Libwebsockets is fundamentally single-threaded and not thread-safe.
Eventually the other thread will try to do operations when the service
thread was in the middle of something and "blow up". As you say -->
> So, it's better if I flag an event from my "hardware" thread to my websocket servicing thread to inform that data is available, so this thread should call libwebsocket_callback_on_writable_all_protocol() in my while loop?
If you'll deal with multiple threads, it's your responsibility to either
work with lws by using extpoll (I explain in a moment) or do the work
external to lws to serailize the actions back into one thread.
> Something like that :
> n = 0;
> while(n >= 0)
> if(event is flag)
> n = libwebsocket_service(context, 50);
Exactly, that'll work out perfectly.
The other way you can come at it is if the "event" is already in
descriptor semantics, ie, a file or socket event you can poll() on. In
that case, you can build monitoring the "event" into the same poll()
action as lws uses, and get rid of the poll() timeout latency. See the
EXTPOLL stuff in the example server for how to share the lws poll loop
with foreign files or sockets.
More information about the Libwebsockets