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

Threading #31

Open
xpple opened this issue Aug 29, 2021 · 1 comment
Open

Threading #31

xpple opened this issue Aug 29, 2021 · 1 comment
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@xpple
Copy link
Owner

xpple commented Aug 29, 2021

The calculations SeedMapper does can be quite resource intensive. Currently, the /locate loot command will scan the entire world until it finds the desired item - which leaves the client hanging for multiple minutes. Don't get me wrong, this particular example is certainly a design flaw on my end and should be prevented. However, even leaving the client hanging for a few seconds can be very annoying and could in the worst case even lead to the player dying. Hence I suggest to execute the commands on a separate, constant thread.

The reason I open an issue is because I couldn't come up with a good way to do this myself. My idea was to have one thread dedicated to the execution of SeedMapper's commands. Execution in the thread can only be stopped by one of two ways: a set time-out or a new command was executed. I know I could just wrap the logic of each command in something like this

new Thread(() -> {
  // code
}).start();

but I think an approach like this doesn't give me enough controll over the threads that are created. Someone suggested using ExecutorService, but I couldn't get that to work. Let me know if you have any elaborate ideas.

@xpple xpple added enhancement New feature or request help wanted Extra attention is needed labels Aug 29, 2021
@networkException
Copy link
Contributor

Well the thing is you can't forcefully end a thread so you'd heave to deal with either checking if a thread was interupted all the time or just deal with having little to no control over them. You could have a mechanism to invalidate the result of a thread after it calls back tho to avoid showing the result of an old command

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants