Naïve plan — Drop-and-Replace
What if we drop-and-replace
postViaSab that follows the same interface as
postMessage but is internally made with SharedArrayBuffer.
Wouldn't this yield much higher throughput? (No, it wouldn't.)
Shortcomings of SharedArrayBuffer
- Fixed in Size
Brane requires explicit schedulers and abstractions to overcome these shortcomings. Drop-and-replace will not be that easy. But what do I mean by this?
Currently, WorkerDOM only has asynchronous data channels. WorkerDOM batch processes requests between agents (i.e., it collects operations and sends them at once.) WorkerDOM will have Scheduler support for general tasks, extended tasks, etc. What kinds of data channels does WorkerDOM have?
Would it be efficient to change all asynchronous data channels to synchronous SharedArrayBuffer?
In easy words, Brane implements a premium-tier SharedArrayBuffer fast lane that will handle priority tasks. It might block user interaction because SharedArrayBuffer is synchronous. This is why we need a proper Scheduler.
Priority: ① User Interaction ② Layout Operations ③ Other Operations
The reason for such SharedArrayBuffer is to eradicate any compatibility issues.
For example, one incompatible operation is
This calculation must process in a blocking condition.
This blocking condition must happen in SharedArrayBuffer.
WorkerDOM cannot handle animation libraries because it lacks synchronous API support.
- Synchronous XMLHttpRequest.
notify()for blocking constructs.
- Replace all unofficial implementation of
getClientBoundingRectin WorkerDOM with
- Geolocation might be easier, because it is an asynchronous API.
- The hard part is transports and schedulers.
We will need a codec to share data on SharedArrayBuffer. Candidates include MessagePack and CBOR. We could also make our codec.
- Better Docusaurus
- Fortune Cookie: Collaborate with those who possess both intelligence and integrity.