Hacker News Reader

Comment by mpweiher | Hacker News Reader

Hmm...

"The server always asks for new location data, every 30 seconds, even when no one is listening."

...

"Our task is to pause the timer when there are no websocket connections and start the timer when a client connects."

That sounds like asking for trouble. Maybe there's something I am not understanding, but why not have the timer run continuously and have the timer action check whether it needs to request location data?

Yes, that will cause the process to wake up every 30 seconds even if there is no action, but unless circumstances are very special that won't be a significant problem.

View on HN

Thanks for reading! I like this suggestion.

The central problem of this post is not whether the timer is running continually. The central problem is how does the timer know when to stop/start making requests.

It's a problem because knowing this depends on access to information that is trapped in a different context. For example, the number of closed connections is only knowable within the context of the connection event handler. So how do you share this information with the timer?

One approach is to mutate global state. You move the information into a shared context where it's accessible everywhere. A second option, which is the focus of this post, is to look for better abstractions. In this case, those are abstractions over time. And when you have those abstractions, you can eliminate the global state.

A question unrelated to your programming concepts: If you only query your source when a request comes in, doesn't the first requester get old data? This is a problem I have faced before.

Couldn't you make the first requester wait until you've made your query?

Sure. But I assumed one goal was to offer low-latency access to a high-latency service. I.E. Act as a cache.

Oh. That would be a tough spot to be in. I assumed that's not an issue here though.

If you work hard enough to remove all timer ticks when they're not needed it can add up to save power.

Please pardon my inexperience, but at what scale does this become significant? Where I've worked readability/clarity/technical-debt have always taken more primary positions as relates to expected costs.

Would you mind linking a reference or example describing the trade-offs in this?

A great effort was untertaken to wean kernels from relying on regular ticks[0][1]. This benefits power consumption on mobile devices but also makes it easier to dedicate some cores 100% to latency-sensitive tasks. Specifically on windows applications have been optimized to make less use of the QueryPerformanceCounter API because it causes the kernel to wake up cores more frequently, again increasing power consumption. Browsers also clamp the frequency of timer wakeups in background tabs to reduce wasted CPU cycles.

A javascript in a browser waking up once a second doesn't matter much. But hundreds of browser scripts and smartphone apps all waking up once a second at different offsets effectively means waking up every few milliseconds.

[0] https://lwn.net/Articles/549580/ [1] https://en.wikipedia.org/wiki/Tickless_kernel

Reply on news.ycombinator.com