[SOLVED] Thread parks forever

User Code & Projects zay-es
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.

1 Like
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.

1 Like
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?

1 Like
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.

1 Like
9

Indeed, it is. GameLoop class.