Subtle race condition with state vs model updates #15
Assignees
Labels
Comments
|
💎 |
|
This also addresses the problem of synchronously updating the size range on rotation. |
adamjernst
added a commit
to adamjernst/componentkit
that referenced
this issue
Apr 23, 2015
This work is aimed at creating a new data source to replace the current implementation. The goals are: - Fix the race conditions described in facebook#15 - Enable batching state updates to the end of the run loop as described in facebook#87 - Enable asynchronous state updates in a less hacky way - Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async) These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
adamjernst
added a commit
to adamjernst/componentkit
that referenced
this issue
Apr 23, 2015
This work is aimed at creating a new data source to replace the current implementation. The goals are: - Fix the race conditions described in facebook#15 - Enable batching state updates to the end of the run loop as described in facebook#87 - Enable asynchronous state updates in a less hacky way - Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async) These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
adamjernst
added a commit
to adamjernst/componentkit
that referenced
this issue
Apr 23, 2015
This work is aimed at creating a new data source to replace the current implementation. The goals are: - Fix the race conditions described in facebook#15 - Enable batching state updates to the end of the run loop as described in facebook#87 - Enable asynchronous state updates in a less hacky way - Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async) These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
adamjernst
added a commit
to adamjernst/componentkit
that referenced
this issue
Apr 27, 2015
This work is aimed at creating a new data source to replace the current implementation. The goals are: - Fix the race conditions described in facebook#15 - Enable batching state updates to the end of the run loop as described in facebook#87 - Enable asynchronous state updates in a less hacky way - Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async) These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
adamjernst
added a commit
to adamjernst/componentkit
that referenced
this issue
Apr 27, 2015
This work is aimed at creating a new data source to replace the current implementation. The goals are: - Fix the race conditions described in facebook#15 - Enable batching state updates to the end of the run loop as described in facebook#87 - Enable asynchronous state updates in a less hacky way - Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async) These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
adamjernst
added a commit
to adamjernst/componentkit
that referenced
this issue
Apr 29, 2015
This work is aimed at creating a new data source to replace the current implementation. The goals are: - Fix the race conditions described in facebook#15 - Enable batching state updates to the end of the run loop as described in facebook#87 - Enable asynchronous state updates in a less hacky way - Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async) These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
adamjernst
added a commit
to adamjernst/componentkit
that referenced
this issue
May 4, 2015
This work is aimed at creating a new data source to replace the current implementation. The goals are: - Fix the race conditions described in facebook#15 - Enable batching state updates to the end of the run loop as described in facebook#87 - Enable asynchronous state updates in a less hacky way - Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async) These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
|
Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed. |
|
This should have been resolved by the transactional datasource, right? Let's close this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's theoretically possible for a race condition to occur if a state update occurs between two model updates. This is so rare we haven't even noticed it when using ComponentKit in Facebook's News Feed, but we should fix it.
My plan is to implement a STM-like system for computing updates to the
CKComponentLifecycleManager's state to resolve this issue.The text was updated successfully, but these errors were encountered: