Grant Davies

So Rust is my jam lately, and I'm unsure how much things translate... But there it's pretty easy to drop a future if it no longer makes sense... So I'd probably wrap that Move or something higher with a monitor that'd abort when things changed.

Makes sense. I guess my point is that it's really easy/tempting to write it in the naïve way I did above (especially if the condition is unlikely to change). So it leads to a lot of code that is 99% right.

Show me the way to write this that is impervious against mistakes.

Yeh, if finding your target really is an operation that needs to be split over multiple frames, in a traditional state machine, wouldn't you need to store the target in a member variable? And therefore wouldn't it be vulnerable to identical failure conditions?

The point is in a traditional state machine, it’s obvious when you abort, because you just don’t call advance. When that’s happening on another thread, you don’t know when it’s safe to tear down because you aren’t the thread calling advance() or idle() or whatever.

Do you need to worry about concurrency though? Async can be single threaded right?

Yes - Even if single-threaded, if it's a state machine with member variables: 1. I can clear/destruct the state if needed 2. I can find it to output in a debug tool 3. I know there is only one copy of it It's the fact that some program state is sort of hidden that bugs me.

I see. Yeh, that's fair. Full disclosure - I was wondering about async in game tech a few months ago so I wrote a little async game to test it.