Remove thread marshalling from stores
Categories
(Firefox for Android :: Tooling, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox147 | --- | fixed |
People
(Reporter: polly, Assigned: polly)
References
Details
(Whiteboard: [fxdroid][group6])
Attachments
(3 files, 3 obsolete files)
Our current implementation of Store spins up a new thread each time state is accessed. This makes the call site's code needlessly complex and error-prone as we often have to pull together composite state from multiple asynchronous requests.
If we remove the thread creation and handling from the Store, this would allow users of a Store to make their own decisions about which thread to use. Typically, we expect main thread to be used as the Store contains accessors for in-memory objects - we don't expect these to be long-running operations.
Updated•10 months ago
|
Comment 1•10 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox for Android::Tooling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
| Assignee | ||
Comment 2•8 months ago
|
||
This required a few changes:
- the Store production code in
lib-stateno longer spawns a new thread when you dispatch a store action. - Because of this, a lot of tests need to have
.join()or.joinBlocking()removed from where they dispatch actions. - Most tests pass after this. But a few fail because either:
- exceptions were being thrown on background store threads
- they relied on store actions not having completed before assertions
Updated•8 months ago
|
| Assignee | ||
Comment 3•8 months ago
|
||
@Ignore-d this in the previous patch, so i'm fixing that separately.
This test manipulates Tab objects, which are being transitioned between active and inactive states by a time-dependent Flow.
We're testing the storage of these objects, so i've pulled out the logic to compare tabs to its own assertTabSame() function, which looks at the contents of the tabs rather than whether they're currently active.
Also don't think we need to use spy() here for the class under test, so i've dropped in the real thing.
Updated•8 months ago
|
| Assignee | ||
Comment 4•8 months ago
|
||
We don't need this any more with single threaded stores, so we can clean up the tests quite a bit.
Updated•8 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
| Assignee | ||
Comment 5•7 months ago
|
||
Second attempt with a smaller patch size. (see patch https://phabricator.services.mozilla.com/D263733 for first attempt)
For now Store.dispatch() returns a dummy Job.
This means the api, which is used in a lot of tests, doesn't need to be changed as part of this patch.
This is temporary and will be cleaned up as soon as we are happy with this change - intention is to have the dispatch function not return and clean up all the join()/joinBlocking() thread wrangling in unit tests.
Changes that have been made:
- remove threading code from Store
- fix tests than rely on multithreading or throw exceptions on background threads
Updated•7 months ago
|
| Assignee | ||
Comment 6•7 months ago
|
||
This means we have to delete join() and joinBlocking() everywhere they are appended to Store.dispatch() (mostly in the unit tests)
| Assignee | ||
Comment 7•7 months ago
|
||
This was previously just a passthrough method so we can remove it now. This simplifies a lot of tests.
Updated•6 months ago
|
Comment 9•6 months ago
|
||
| bugherder | ||
Comment 10•6 months ago
|
||
Updated•6 months ago
|
Comment 11•6 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/ee96a94e9c0a
https://hg.mozilla.org/mozilla-central/rev/343ae3f24eb5
Updated•6 months ago
|
Description
•