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)
Thu, Nov 7, 3:08 AM
Unknown Object (File)
Oct 21 2024, 10:45 AM
Unknown Object (File)
Oct 15 2024, 7:25 PM
Unknown Object (File)
Oct 15 2024, 7:25 PM
Unknown Object (File)
Oct 15 2024, 7:25 PM
Unknown Object (File)
Oct 15 2024, 7:25 PM
Unknown Object (File)
Sep 4 2024, 2:40 PM
Unknown Object (File)
Sep 4 2024, 2:40 PM
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
No Lint Coverage
Unit
No Test Coverage

Event Timeline

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