Single Thread Scheduled Executor For Processing

[Dane]

I was wondering what your opinions are of this:

 

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45

import java.util.concurrent.Executors; import java.util.concurrent.ScheduledExecutorService; public class Game implements Runnable {    private ScheduledExecutorService service;    private boolean running;    public Game()    {       this.service = Executors.newSingleThreadScheduledExecutor();       this.start();    }    public void start() {       if (!running) {          this.service.submit(this);       }    }    public void stop() {       this.running = false;    }    @Override    public void run() {       try {          // Do stuff here.          // Sleep         Thread.sleep(50);          // If we're still active, re-submit.         if (this.running) {             this.service.submit(this);          }       } catch (Exception e) {          e.printStackTrace();       }    } }

[Danny02]

what is wrong with a simple while loop^^
this is just overkill

[sproingie]

Much as I like j.u.c and think everyone should use Executors ... I have to agree, how's this superior to a plain loop?

Games published by our own members! Check 'em out!

[Dane]

Well actually I never said this was superior to anything, I just asked for your opinions of it. 

[sproingie]

I suppose you could say it's properly tail recursive by way of using the executor as a trampoline, though with no proper way to take parameters or return output, that's not a very interesting property, just a very expensive loop.  If the executor were shared with other Runnables using it you'd have a poor man's cooperative scheduler, emphasis on "poor".   Check out the green threads post for a heavy duty version of the same.

[matheus23]

I'm pretty sure this is much slower than a simply while loop.

And It's not tail recursive. If it would be tail recursive this would have been a cracy mess. The game would crash when reaching the maximal stack size, since afaik Java / JVM hasn't got tail calls implemented yet.

[sproingie]

It's "tail recursive" in that run() reschedules itself then exits.  Similar to how javascript typically runs infinite loops.  It also doesn't have any way to take input or produce a return value, though I suppose it would be simple to modify it for either.  

Going back to my comment about sharing the executor, it's not a bad thing to experiment.  I'd encourage trying out that approach with several such runnables.  Next, drive their execution from a blocking queue, and you have an actor system.