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)
Mon, May 6, 3:14 PM
Unknown Object (File)
Tue, Apr 23, 1:50 AM
Unknown Object (File)
Tue, Apr 23, 1:50 AM
Unknown Object (File)
Tue, Apr 23, 1:49 AM
Unknown Object (File)
Tue, Apr 23, 1:47 AM
Unknown Object (File)
Sun, Apr 21, 4:42 PM
Unknown Object (File)
Apr 2 2024, 5:10 AM
Unknown Object (File)
Mar 26 2024, 8:55 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