Page MenuHomePhabricator

[web] Handle shared worker message sequentially
ClosedPublic

Authored by michal on Mar 11 2024, 6:35 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 24, 7:18 AM
Unknown Object (File)
Tue, Dec 24, 7:18 AM
Unknown Object (File)
Tue, Dec 24, 7:17 AM
Unknown Object (File)
Tue, Dec 24, 7:17 AM
Unknown Object (File)
Thu, Nov 28, 6:29 PM
Unknown Object (File)
Thu, Nov 28, 4:31 PM
Unknown Object (File)
Nov 7 2024, 3:08 AM
Unknown Object (File)
Oct 21 2024, 10:45 AM
Subscribers

Details

Summary

ENG-6209

On native we have e.g. crypto thread or database thread to guarantee that operations will be happen sequentially. This diff brings the same for worker (db, olm) operations. I considered having different "task queues" per message db (e.g. db or olm) but I don't think it's worth as it complicates the code a lot (based on the native code). If this turns out to be a performance problem we can consider changes.

Depends on D11275

Test Plan
  • Test if the app still works
  • Add a new dummy worker message and add await new Promise(resolve => setTimeout(resolve, 3000)); to it, so resolving it takes 3s
    • Without changes if multiple requests were scheduled then all of them resolved after ~3s one after another
    • With the changes there was a 3s delay between each of them

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Mar 18 2024, 5:15 AM