-
Notifications
You must be signed in to change notification settings - Fork 1
Stop connecting to remote location from main thread #11
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
base: master
Are you sure you want to change the base?
Conversation
Alexdoru
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's the best thing to do to put the entire config parsing and file reading on a separate thread.
I think it would be better to only queue the request on a separate thread and have it load your data in a local variable. And then you can queue a task on the main thread using
// this code here should be on your separate thread
final Map<> localVar= whatever you are doing
Minecraft.getMinecraft().func_152343_a(() -> {
// the code here will run on the main thread,
// in the runTick loop (so only when the game have fully booted)
// you can use the final localVar
return null;
});
Why do you think so? Putting not just the request in the thread would take the (very small) load from reading and parsing off of the main thread. Using the task scheduler makes this code much more complicated because
|
|
@Alexdoru @glowredman any news here? |
|
I already responded, the correct way to do multithreading is to put only the request on a separate thread and then queue a task on the main thread with the results of the request |
|
Did you respond on Discord? I can't remember you saying anything specifically about this:
|
you shouldn't lock the entire class, you need to make just the request is a separate thread not the whole thing
just split the method in two and queue a task on the main thread once the request returns adding two synchronize keyword and spawning a new thread is a lazy solution to multithreading your code, if you don't want to do it properly then just close the pull request. Also your code isn't even thread safe because of the public fields that are accessed from both the main thread and the other thread |
|
@Alexdoru done |
My first steps into multithreading... I hope this is the correct way to do it. The idea is to spawn a new thread which calls
Config.init(). As long as that method doesn't return, the entireConfigclass is locked and other threads can't access its fields and methods (which are all static).