Feature Mod: Add metering, parallelism & throttling options to AddEventListenerOptions

Sylon Zero sylonzero at gmail.com
Mon Nov 27 22:50:23 UTC 2017


Sorry, looks like I've posted this in the wrong spot. I will move it to the
WHATWG  group, as recommended.

On Mon, Nov 27, 2017 at 3:49 PM, Sylon Zero <sylonzero at gmail.com> wrote:

> *Core Problem Statement* Processor functions that subscribe to events via
> a topic string may need to be prioritized for processing based on the topic
> itself. Conversely, certain events may be more numerous but should not
> limit the ability of the JS environment to respond and process other
> events, that may be more critical to either the User Experience (UX) or
> integrity of the system (e.g. events that trigger saving data to a
> back-end).
>
> *Background Information* As Browser/CommonJS environments bring paradigms
> like UI event handling and back-end event handling into the same problem
> space, it is useful to apply common patterns used in Message-based
> Publish-Subscribe environments with message brokers, which is what the JS
> execution context often behaves as. The use case here is to ensure that one
> kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate
> or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to
> massive differences in event volume or conversely, expensive operations
> that block the execution thread in question.
>
> *Proposed Solution* Add metering options to the addEventListener *Options*
>  configuration object. These options control how the JS execution
> environment controls the throttling/firing of event handler instances in
> response to events that match the topic string of the subscription created
> by addEventListener.
>
> Proposed options:
>
>    - maxInstances [Number / Function] used to decide how many event
>    listeners can be invoked before throttling occurs. Throttling does not lose
>    events but simply queues them.
>    - throttlingQueueLength [Number] used to maintain an in-memory queue
>    of un-processed events per Topic string, after throttling kicks in.
>    - throttlingQueuePolicy [String] Values could be exception - throws an
>    exception when the queue length is exceeded, rolling - drops the
>    oldest events and pushes newer ones into the queue, expand- allow the
>    queue to expand to cover all events.
>
> *Additional Options* It might be even more useful if the options allowed
> targeting or creation of Web Workers (or Node child processes, depending on
> the execution context) based on the event handler configuration. This could
> potentially target CPU cores and/or O/S child processes / threads
> (depending on the O/S terminology for parallel execution).
>
> *Related Thread* The proposal identified in the link below (by Šime Vidas) could
> be part of this solution as it defines other metering options around
> debounce (which improves scale around event handling, which is in the same
> problem space) and handling throttling through frequency, which should be
> one of the alternatives in addition to my proposal above (as I believe they
> are orthogonal): https://discourse.wicg.io/t/add-event-throttlin
> g-and-debouncing-to-addeventlisteneroptions/2436/19
>
> Sai Prakash
> @SylonZero
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171127/490e0cec/attachment-0001.html>


More information about the es-discuss mailing list