[Libwebsockets] polling for file descriptor i/o

Andy Green andy at warmcat.com
Mon Mar 6 00:00:30 CET 2017

On March 6, 2017 4:23:47 AM GMT+08:00, Per Bothner <per at bothner.com> wrote:
>On 03/05/2017 10:45 AM, Andy Green wrote:
>> On March 6, 2017 2:04:36 AM GMT+08:00, Per Bothner <per at bothner.com>
>>> I do notice that poll is being called very frequently via
>>> the top-level lws_service function.  This seems to prevent
>>> the server from going to sleep when there is no activity,
>>> which is bad for energy usage.
>>> I tried setting the timeout parameter to -1 in the
>>> lws_service call, but then it just froze.
>> What happens if you set it to like 1000 (1s)?
>Noticable delays.

Hm... it's definitely sleeping then.  Which is good.

Delays shouldn't occur because everything should be happening on fd events or event mask changes.

The usual cause is the fact that poll() does not respond to changes to his .events masks until he exits and re-enters.  If another thread is asking for callback-on-writeable for example, you should implement LWS_CALLBACK_GET_THREAD_ID in protocols[0] to return the tid.  Lws will check it and if different from the service tid, will interrupt poll() automatically when the other thread changed an event mask.  The tid is opaque it's just checked if it's the same as the one doing the service.

>With 100ms timeout I don't notice any sluggishness.
>> If something is signalling POLLIN or POLLOUT (or POLLHUP...) the
>poll() will end early.  Otherwise the poll() will block / sleep for the
>timeout duration which is perfect for energy usage.
>Better for energy usage if the timeout duration were infinity.

Timeout code could compute when the first timeout is ripe I suppose.  But that also takes energy when there are many connections... and won't fix whatever experiences latency in your setup.  So they are two separate issues.

>> If nothing happening cpu is very low, like 0.01%, if something
>continuously happening it will be 100%.  So is something always wanting
>It's not my field, but I would expect the CPU could go into "deeper
>(and thus use less energy) if it didn't get woken up by do-nothing
>multiple times a second.

Lws just wants a wakeup on the order of once per second, which is a very long time for a modern core.  Intel power management is per-core and highly opportunistic.  If it requires a smaller timeout for latency that's something that can be solved.


More information about the Libwebsockets mailing list