Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash: sometimes will crash at this point, what can i do to find the root cause #497

Open
LivenChief opened this issue Dec 6, 2022 · 11 comments

Comments

@LivenChief
Copy link

image

@mjarvis
Copy link
Member

mjarvis commented Dec 6, 2022

Looking at the left side, it appears this is breaking on a background thread. ReSwift does not support multi-threading and will crash if you dispatch an actions from multiple threads. Take a look at the dispatch you're making an ensure its sent on the thread you're using ReSwift (usually main)

@LivenChief
Copy link
Author

LivenChief commented Dec 7, 2022

our structure:
viewController contains some featureView, such as featureView1, featureView2, featureView3.
each featureView will subscribe store when viewController viewDidLoad, and will dispatch som action sometimes too.
is it right?

@mjarvis
Copy link
Member

mjarvis commented Dec 7, 2022

Yes, this is fine.

@mjarvis mjarvis closed this as completed Dec 7, 2022
@mjarvis mjarvis reopened this Dec 7, 2022
@mjarvis
Copy link
Member

mjarvis commented Dec 7, 2022

Sorry, mistakenly closed and submitted my comment prematurely. Subscribing and dispatching in viewDidLoad sounds fine, yes.

@LivenChief
Copy link
Author

It is difficult to avoid dispatching on different threads, because a thunk call api response may be dispatched in one of the featureViews, then we will dispatch response date in network response threads(usually not main)
can i solve in this way?
image

@LivenChief
Copy link
Author

Another thing that block me is when to clear the data on the store? I hope you can give me some advice, thank you very much

@mjarvis
Copy link
Member

mjarvis commented Dec 8, 2022

I would not recommend async'ing all function calls, there are many cases where you want dispatches to happen synchronously (eg user input). You should instead consider each thunk and ensure its asyncing to the main thread itself before dispatch(foo) if needed.

@DivineDominion
Copy link
Contributor

@LivenChief +1 to what @mjarvis said.

This is still a good rule of thumb:

I start with the ideal assumption that everything will run on the main thread.
https://inessential.com/2014/03/08/api_design_the_main_thread_and_queues

Your goal then would be to make it so that everything that dispatches to a BG queue eventually ensures that the main queue is reached again.

Sprinkle in some assert(Thread.isMainThread) (via https://inessential.com/2020/01/20/on_replacing_operationqueue) and you can detect where your assumption about being on the main thread is violated, and by whom.

@LivenChief
Copy link
Author

thank you very much,guys

@LivenChief
Copy link
Author

LivenChief commented Dec 9, 2022

Hi @DivineDominion @mjarvis
mine viewController contains many featureView, each featureView will subscribe store, I want to last receive the store data featureView to clear store data nil when i dispatch action change store data, so that i can keep store data more clear not bloated. but i found that subscriptions is an unordered collection Set
How i can know which subscription is the last one receive data?

@DivineDominion
Copy link
Contributor

@LivenChief Sorry, I can only 80% follow :)

If you want to make sure that N subviews receive a state update in a specific order, don't subscribe each of these. Instead, subscribe a common ancestor and make it forward the relevant information to its child views. (In technical terms, it's up to you to express the intent of updating views in a specific seauence.)

If I'm getting this wrong, can you share a pseudo code example?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants