[634] Main thread events

[clem585]

Hmm, on my linux system, it works, on my windows system it doesn't.

Try this?

ScheduledExecutorService ses = Executors.newSingleThreadScheduledExecutor(r -> {
    val thread = new Thread(r);
    thread.setPriority(Thread.MAX_PRIORITY);
    thread.setName("abc");
    return thread;
});
ses.scheduleAtFixedRate(runnable, initialDelay, period, timeunit);

[Makar]

Try this?

ScheduledExecutorService ses = Executors.newSingleThreadScheduledExecutor(r -> {
    val thread = new Thread(r);
    thread.setPriority(Thread.MAX_PRIORITY);
    thread.setName("abc");
    return thread;
});
ses.scheduleAtFixedRate(runnable, initialDelay, period, timeunit);

Yeah I just created a thread factory for it that essentially does just that and it ended up working now. This is nice as well since now if anything goes wrong on that thread, it actually is manageable and can be cleared off the scheduler and re-added in the event of a serious error.

Unfortunately, flushing the buffer on the timer doesn't fix the object animation sync. I'm gonna dig around refactoring my client some more and see if I can learn more about the timer that is actually choosing which frame of the animation to start on for those objects.

If you or anyone else ever wants to help with that, the client is here, open to any and all pull requests. [Only registered and activated users can see links. ]

[Kris]

Yeah I just created a thread factory for it that essentially does just that and it ended up working now. This is nice as well since now if anything goes wrong on that thread, it actually is manageable and can be cleared off the scheduler and re-added in the event of a serious error.

It's possible you might've used one of the other methods, e.g. scheduleAtFixedDelay, which just sleeps for 600ms between every execution, very similarly to what Clem's original implementation did.
Something I'd also like to point out - that I should've pointed out way earlier - is the inaccuracies with System#currentTimeMillis.

The java.lang.System.currentTimeMillis() method returns the current time in milliseconds. The unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger.

For example, many operating systems measure time in units of tens of milliseconds.

Copied this from google, but basically long story short - depending on your operating system, the granularity could be quite big and this has massive effects over time. It's basically as if you're putting the thread to sleep for anywhere from 590-610 milliseconds every single cycle, not knowing what it really is because the method just isn't that precise. This is assuming the granularity were 10ms(I'm actually not certain if it goes both ways though so correct me if needed there). This can overall result in a massive deviation over long periods of time. The System#nanoTime - which is used by the executors too - is far more precise, but at the same time more expensive to call, although this is only relative to the currentTimeMillis, it is still extremely fast in reality.

[Greg]

Because.. 1) You're restricting it to sleeping a minimum of 50ms even if the tick takes longer than 600ms, in which case it should be trying to catch up, you should never slow it down further.
and 2) The overall mechanic will result in your average tick taking 600.5ms, not the 600ms you should be aiming for. I suggest using a single thread scheduled executor to achieve this, the scheduleAtFixedRate method takes care of the time fluctuating, so your ticks will be more in lines of.. 600ms, 600.5ms, 599.5 ms etc. It will correct the previous tick's leftovers - or shortgoings with the next tick.

Yeah I just created a thread factory for it that essentially does just that and it ended up working now. This is nice as well since now if anything goes wrong on that thread, it actually is manageable and can be cleared off the scheduler and re-added in the event of a serious error.

Unfortunately, flushing the buffer on the timer doesn't fix the object animation sync. I'm gonna dig around refactoring my client some more and see if I can learn more about the timer that is actually choosing which frame of the animation to start on for those objects.

If you or anyone else ever wants to help with that, the client is here, open to any and all pull requests. [Only registered and activated users can see links. ]

Worth keeping in mind uncaught exceptions in an executor will cause it to fail silently and stop processing future ticks without warning

[Kris]

Worth keeping in mind uncaught exceptions in an executor will cause it to fail silently and stop processing future ticks without warning

For anyone wondering why this is, it's because the threadpool(s) come with a limited number of threads(unless you use the resizable one although I'm not sure how well that scales with thread deaths), and every time there is an uncaught exception, the thread dies as it normally would. Eventually, you're left with nothing more than a boss thread which is meant to send out the requests to the worker threads but they'll all be dead at that point and nothing will be executed.
Experienced this plenty of times myself in the past

[Makar]

It's possible you might've used one of the other methods, e.g. scheduleAtFixedDelay, which just sleeps for 600ms between every execution, very similarly to what Clem's original implementation did.
Something I'd also like to point out - that I should've pointed out way earlier - is the inaccuracies with System#currentTimeMillis.


Copied this from google, but basically long story short - depending on your operating system, the granularity could be quite big and this has massive effects over time. It's basically as if you're putting the thread to sleep for anywhere from 590-610 milliseconds every single cycle, not knowing what it really is because the method just isn't that precise. This is assuming the granularity were 10ms(I'm actually not certain if it goes both ways though so correct me if needed there). This can overall result in a massive deviation over long periods of time. The System#nanoTime - which is used by the executors too - is far more precise, but at the same time more expensive to call, although this is only relative to the currentTimeMillis, it is still extremely fast in reality.

It is very possible I might have had that method in there at first and thought that I used both but just autocompleted to the previous. But yeah that's essentially what I gathered from researching the problem when I realized it existed a few days ago. It's funny that this thread got posted when I was seriously trying to improve the network handling and stuff. I ended up finding that FPS manager in the client from trying to get down to the logic that handles which frame the object animations should be on and turns out Jagex has their own custom native nanotime method that could be slightly faster.

Worth keeping in mind uncaught exceptions in an executor will cause it to fail silently and stop processing future ticks without warning

Yeah thanks for the head's up. My task manager does handle and log all exceptions so this will help with stability when errors do occur for sure. Also won't halt the server's reboot process anymore which is nice.

For anyone wondering why this is, it's because the threadpool(s) come with a limited number of threads(unless you use the resizable one although I'm not sure how well that scales with thread deaths), and every time there is an uncaught exception, the thread dies as it normally would. Eventually, you're left with nothing more than a boss thread which is meant to send out the requests to the worker threads but they'll all be dead at that point and nothing will be executed.
Experienced this plenty of times myself in the past

Yeah dude dealing with those thread death errors and deadlocks are probably the most annoying to debug for me lmao. Also for players too since they'll start reporting side effects of the bug rather than what caused it so the error log is the only place to go.