Throttling wait/wake signalling frequency in background pages for power efficiency reasons?

[taisel]

I'm opening as a question to determine the full impact and issue spectrum of using futexWake to proxy eventing signals from main thread to webworkers. Namely, to decide if there's any signals that should be prohibited from propagation or throttled for host computer power/efficiency reasons, or to prohibit improper eventing techniques for events that should exist within a webworker itself.

This question was brought up after slight discussion on the implications of requestAnimationFrame existing on main thread and not webworkers temporarily, and the impact that will cause for developers trying to find alternative solutions that are not ideal (or more power hungry).

[lars-t-hansen]

The main thread can call futexWake on any shared location, without restriction. If any worker is waiting on that location with futexWait when the wake is called, then the call to futexWait will return. All workers that wait on that location in that manner will be woken at that time.

(If the question is asking anything other than that then I don't know what it is asking.)

[taisel]

The question is asking whether or not there's power efficiency concerns that should be looked into, via possibly prohibiting some signalling. The idea that brought up this question was the setInterval clamping to 1000 milliseconds that vendors do when a webpage is hidden. There may be techniques that subvert such clamping with the webworker/sharedmemory API model.

[lars-t-hansen]

I see. I will update the subject line and reopen then.

[lars-t-hansen]

So if we switch from futexes to synchronics (issue #12) it's going to be tricky to do any effective throttling of a determined adversary. The reason to make that switch is to increase signaling speed, and the way that is done is to spin on a memory location for a little while to check for an update; only if a signal is not forthcoming will we go into a full-fledged sleep. The runtime and/or OS are not going to be involved at all if the signal arrives quickly. I guess we can use a parameter that's stored in memory for the spin count and set this parameter to zero, when the page is put into the background.

But i'm not sure there are any new capabilities here. Already, an adversary can fork off a worker that just spins and sends messages to the main thread at whatever interval it chooses. (To avoid spinning it can presumably engage in some async operation that takes a little while, too, if there are async operations whose frequency are not subject to throttling. I'm thinking database ops, for example.)

Generally this strikes me as a quality of implementation issue, not a spec issue. Also, it looks like I'm not the first to think of messages as a workaround for the throttle: http://dbaron.org/log/20100309-faster-timeouts. That hack doesn't require a spinning worker, either.

[lars-t-hansen]

I will add a Note to the section on futexWake to note that, though it wakes the waiters, the waiters will only eventually need to be woken, and note that that allows throttling for the reasons specified in this bug.