Is anyone interested in a JME scheduler?

Contribution Depot
1

In Minecraft, there is a server software called Bukkit that allows for dynamically loaded plugins. One of the APIs it offers is a scheduler that can run tasks either as soon as possible or at an arbitrary point in the future. It can also run these synchronously or asynchronously. Currently, JME implements a minimal version of this in the form of the enqueue() methods. I am thinking that expanding this to a separate scheduler class that offers several methods (listed below) would be a good idea. This class could either be an optional AppState like the ScreenshotAppState or a module that is part of either Application or SimpleApplication similarly to the InputManager and AssetManager. I would like to know of anyone shares my opinoin that this is a good idea. I plan to implement it in a pull request if there is support for it.

Available Methods:

  • scheduleSynchronousTask(Runnable/Callable task); (schedules a task to run on the render thread as soon as possible, similar to enqueue)
  • scheduleAsynchronousTask(Runnable/Callable task); (schedules a task to run on a worker thread as soon as possible)
  • scheduleAsynchronousDelayedTask(Runnable/Callable task, float delay); (schedules a task to run on a worker thread after delay seconds have passed)
  • scheduleSynchronousDelayedTask(Runnable/Callable task, float delay) (schedules a task to run on the render thread after delay seconds have passed)
  • scheduleAsynchronousTimedTask(Runnable/Callable task, float delay, float interval) (schedules a repeating task that first runs after delay seconds and then runs again every interval seconds, all runs of this task are done on worker threads)
  • scheduleSynchronousTimedTask(Runnable/Callable task, float delay, float interval) (schedules a repeating task that first runs after delay seconds and then runs again every interval seconds, all runs of this task are done on the render thread)

Each of these methods would return a ScheduledTask object that has methods to change the delay, interval, etc. and to cancel the task. Another alternative is to have a single scheduleTask() method that takes a ScheduledTask object as a parameter. Users would construct their own ScheduledTask and there would be a separate subclass for each of these methods or there would be a constructor like the following:

new ScheduledTask(ThreadMode.ASYNCHRONOUS, RepetitionMode.TIMED, delay, interval, runnable/callable);

1 Like
2

Hey John, nice to see a familiar face here.

I personally would quite like a system like this. Running tasks at intervals is much simpler than having to check for intervals or time passed in an update method, or running an async task (which can cause all sorts of problemss).

Do you have any uses in mind for this that could not be implemented already with either an async task or checking the time passed in an update method?

3

This is a nice utility for someone maybe (someone who doesn’t already understand that the JDK provides exactly this already)… but it’s not really for core.

JME core already includes too many things that have no concept of ‘game time’ and thus completely break down when a developer wants to implement ‘pausing’. This would be yet another thing.

That being said, things don’t have to go into JME itself to be useful to someone. Put them up somewhere and let folks use them if they want.

1 Like
4

It would basically provide the same thing as counting down in the update method. The reason I would want this is because I find myself writing such countdown code quite a lot and I think it would be better to have a more organized setup. So, no, it wouldn’t make new things possible but it would make existing code potentially cleaner.

5

I know that the JDK already implements something similar – in fact I was planning on basing my implementation off of the JDK’s. This would be better because it would allow for something that is more integrated with JME and would also provide a system that can be used for both synchronous and async tasks. Lastly, it would allow repeating and delayed synchronous tasks.

I’ll probably take this and my SimpleAppState and place them in a separate library on GitHub. Would it be okay if I made a few references to this library in the wiki in the appropriate places so that anyone who could benefit from it is aware of it or is this considered against the rules?

6

Depends on where you put it. If it’s under some “third party tools” then it’s ok.

Adding everything and the kitchen sink into JME is not really better. Every unnecessary tie made is a limitation, not a benefit. I see no good reason to tie a JDK scheduler together directly with JME… but as said, you are welcome to do whatever you want in your own code. As a general point, putting so much game logic right into the visualization (as your scheduler implies) is kind of a bad practice.

Not sure I understand how the asynch/synch thing is any different than the JDK scheduler. Or did you mean to compare it something else?

7

I was thinking that under third party tools along with mentions in other places it could be useful such as in the article about concurrency. I wouldn’t make it seem like an official JME tool.

It would allow for a repeating task to be scheduled to run every, ie. 5 seconds but instead of only allowing as part of a ExecutorService’s threads it would allow it as part of the render thread. It is basically an enqueue that runs at an interval. Basically, in everything I wrote above “sync” means “on the render thread” and “async” means “on an ExecutorService’s thread.”

As a brief example see the code with and without the scheduler:

Without Scheduler:

public void simpleUpdate(float tpf){
    countdown -= tpf;

    if(countdown < 0f){
        doSomething();
        countdown = INTERVAL;
    }
}

With scheduler:

public void simpleInitApp(){
    getScheduler().scheduleSyncTask().scheduleSynchronousTimedTask(() -> doSomething(), 0, INTERVAL); //runs doSomething() on the render thread every INTERVAL seconds
}

Also, I don’t see this as tying a JDK executor into JME but rather as a simple, powerful, unified interface for deferred and threaded execution of code. it could also potentially make thread management very simple: if it is scheduleAsync() then don’t access the scenegraph, otherwise, it’s fine.

8

Sounds like a good idea to package that into a library for others to use. Put up a github/bitbucket repository, a build system and maybe even put the jar into maven central so others can benefit form it.