[Libwebsockets] a question about poll timeout change in libwebsockets.

Andy Green andy at warmcat.com
Sat Jun 6 06:11:24 CEST 2020

On 6/6/20 4:43 AM, huangkaicheng wrote:
> Hi,
>     I have a question, In 2.3version, timeout_ms of poll is setted by 
> lws_service(struct lws_context *context, int timeout_ms)directly as 
> follows;
> and In stable 4.0 version, it has changed as follows. What is 
> consideration for the changes of timeout. If timeout_ms is still setted 
> by lws_service(struct lws_context *context, int timeout_ms) in 4.0 
> stable, it will OK?
> we found timeout is up to 1000ms sometimes.

In v3.2+, the poll wait timeout can be up to two weeks if nothing to do. 
  The point is as soon as "something to do", a network event or a 
scheduled event on the event loop, he immediately wakes up and does it. 
He only remains sleeping if nothing to do.

In older lws, it requires to wake every second or so and check timeouts.

At v3.2, I rewrote how time works inside lws to use lws_sul, a sorted 
list of future schedules events that is inexpensive to maintain


this gives a lot of new capabilities, applications can schedule any 
number of arbitrary callbacks at us resolution from the event loop 
thread context, they don't have to use the protocol callback any more.

In addition, lws adjusts the poll wait timeout to the *earliest* 
scheduled event... the scheduler list is sorted so this is very cheap to 
find out.  That means that the time spent asleep in the poll wait is 
maximized which is a good behaviour for system power.

In master (soon to be v4.1) this is further extended to two sorted 
lists, one as before and the other containing events capable to wake the 
system from suspend.  So it is also easy to discover how long to set the 
suspend wake timer of your system.

This increasingly aligns the poll() event management with all the other 
event libs... if you build against libuv or whatever, lws_service() 
never returns until the context is destroyed.

In short you shouldn't try to fit things around lws_service() because 
eventually, it will behave like all the other event loops and not return 
until the context is destroyed.  If you describe what you're trying to 
do with that I can try to suggest a better way.


More information about the Libwebsockets mailing list