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

Multithreading crashes #25

Open
IllusiveS opened this issue May 13, 2020 · 2 comments
Open

Multithreading crashes #25

IllusiveS opened this issue May 13, 2020 · 2 comments
Labels
bug Something isn't working

Comments

@IllusiveS
Copy link

So i took some time to do some debugging, and since there is no issue for that, im creating a new one to share some of my basic findings.
It seems like an issue with Node duplication, my first idea was that the nodes that are being duplicated are part of thread-unsafe tree, but that does not seem to be the case.
Simulation part seems to be woring, function returns status OK. It is something after that that is messed up.

@HungryProton
Copy link
Member

Just to give a bit of context for other people : multi-threading is currently disabled in core/concept_node.gd, line 87

call_deferred("_run_background_generation") # Single thread execution
#thread_pool.submit_task(self, "_run_background_generation") # Broken multithread execution

On my end, the thread pool seems to do its job, and the very first generation always works. When changing anything, the editor goes into an infinite loop, complaining about rich_text_label.cpp l:170

Is this the case for you too?

@HungryProton HungryProton added the bug Something isn't working label May 28, 2020
@HungryProton
Copy link
Member

HungryProton commented May 30, 2020

Should be fixed in 9e6d16f
Probably needs more testing before merging this in a stable release

More details on the issue: The GraphEdit and its GraphNode children needs to regenerate their GUI sometimes (mostly when switching from the ConceptGraph to the Editor dock).
If a simulation is launched before all the GraphNodes are ready, they may try to access elements that are being modified by the main thread, causing an infinite loop. I added extra checks to prevent this but there's no guarantee there isn't something else that could also trigger the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants