[Telemetry] Port JS code to a worker

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
5 years ago
10 months ago

People

(Reporter: Yoric, Unassigned)

Tracking

(Blocks: 3 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Async:team])

Now that chrome workers have a module system (bug 872421), we can start working on implementing libraries.

The objective if this bug is twofold:
- make Telemetry usable from a chrome worker, wrapping this as a module;
- make as much as possible of existing Telemetry clients actually place calls to a Telemetry worker.

Cc-ing Nathan to confirm that it makes sense and to determine which parts of Telemetry can be ported to a worker.
Flags: needinfo?(nfroyd)
Makes sense to me.  The I/O is likely the first place to start porting operations to workers.  I'm not entirely sure how much other stuff will port easily given dependences on XPCOM.
Flags: needinfo?(nfroyd)
Blocks: 899831
Whiteboard: [Async]
So, TelemetryPing.js has a fair share of synchronous I/O, with a flag to ensure that this I/O is specifically synchronous. Nathan, what would I break if I just made all this I/O asynchronous? (except the test that tests that it's synchronous)
(In reply to David Rajchenbach Teller [:Yoric] from comment #2)
> So, TelemetryPing.js has a fair share of synchronous I/O, with a flag to
> ensure that this I/O is specifically synchronous. Nathan, what would I break
> if I just made all this I/O asynchronous? (except the test that tests that
> it's synchronous)

Should be hardly anything besides the tests.
Depends on: 643325
Depends on: 902434
Depends on: 913070
Whiteboard: [Async] → [Async:team]
Closing this. We might re-visit it in the future from a fresh Angle. Is worth noting that the Quantum Flow initiative didn't highlight this being a problem though.
Status: NEW → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.