[SOLVED] Thread parks forever


#1

I start thread like this (in Main):

...
exec = Executors.newSingleThreadScheduledExecutor();
exec.scheduleAtFixedRate(new MovementThread(this), 0, 20, TimeUnit.MILLISECONDS);
...

MovementThread:

public class MovementThread implements Runnable {
    
private static final float tpf = 0.02f;
    private AppStateManager stateManager;
    
    public MovementThread(Application app)
    {
        stateManager = new AppStateManager(app);
        stateManager.attachAll(
                new Movement(),
                new Steering()
        );
    }
    
    public void run()
    {
        stateManager.update(tpf);
    }
}

is this correct way to do it? I mean it works for few random minutes, then stops working. Nothing tremendous happens at that time, no huge object’s additions, heap and cpu usage look calm. Are there special prerequisites for those systems I attach (considering they work well in single-threaded configuration)? Cheers.


#2

You dont need to create a new appstatemanager. Get it from app.getstatemanager(). Or attach states in a thread. Or use a thread. Apart from that it looks fine.


#3

And i mean… you shouldnt really have to attach an appstate more than once. I cant see many cases for doing so. You probably want to make a Control (probably just an AbstractControl) for steering.


#4

Oh, they both are attached once per appstate, I don’t attach them in main if I use this scheme.


#5

But why add them in a thread? Do they take a long time to initialize or something?

The update loop does what you are essentially doing. I think it might be easier for you to read the tutorials than for me to explain why this is wrong fundamentally and mechanically.


#6

There is seriously no good reason to run app states on a separate thread. Either you want to reuse existing app states or you just like having something run your code for you. If the first case, you can’t reuse those app states anyway because mostly likely they are expecting to run on the render thread. In the second case, why bother with AppStates which have a million things you don’t want just to get an update method?


#7

This kinda confuses me… you mention certain conditions I can barely meet in another thread? What I’m trying to obtain is to get fixed update call rate while leaving all those init/cleanup facilities (i.e. EntityData, EntitySet’s picking) in place as they were in regular system. Now I extend BaseAppState (from lemur.event), I take it, I shouldn’t, so what do I do then? I mean I see your own infrastructure of AbstractGameSystem/GameSystem/GameSystemManager etc, but no clue of how this would do the task… or rather getting constant call rate is something not really good in terms of design? Even if so, one system can have a priority over another, how do I achieve that then? Should I extract the data and supply them to somewhere that will update them and then sync this back with main update manually?


#8

So, you want a multithreaded infrastructure with a bunch of methods you don’t need just to call an update method at a fixed interval? Seems like a waste to me.

re: “the way I do it”… you can probably check my last 10000 threads for the examples I post constantly. Or I guess I can post the fully working examples again…

It’s a fully working example. It works fully. Has networking. Proper separation between visualization and ‘business logic’, etc… Fixed updates… everything you want is right there.

App states are for visualization. That’s why they run on the render thread.


#9

Indeed, it is. GameLoop class.