I am looking for a system for building state machines with timed/scheduled transitions, and with events that happen periodically during a given state. I can implement it myself, though I feel like this is a common enough requirement that there would be a category of software for it.I don't need a library recommendation, vendor, etc. I just don't know what to call this thing, and thus what to google, because it isn't a cron and it isn't a message queue. I don't know if such a server-side layer even exists currently, but I'm hoping to find an indication one way or the other. If this type of question is a reason for down votes and close votes, definitely indicate that, and maybe point me to another SE, or suggest improvements.The application I have in mind is a timed video game event system, like those you might see in an MMORPG (periodic monster spawns, timed escalating waves, failure timer, scheduled event starts), or in a trivia bot (per-question timer, time between questions, round timer), etc. It won't be used for simulations, physics, etc, so I won't be throwing real-time (sub-second) granularity events at it.The system I have in mind would be some sort of hybrid pub/sub and scheduling system, operating entirely server-side. It would be somewhat like a Javascript setTimeout, except with a more reliable mechanism, probably with a 1 second resolution, and with the ability to pass parameters explicitly when you schedule the timeout. It probably would also have some sort of global monitoring for ops purposes, and maybe would have some sort of support for scaling to multiple systems.I don't know if I will need to roll my own, or if there are more generic systems that already do what I want them to do. I would prefer to use an existing system if possible. There is some common server tech that is similar, but I don't think it quite does the job.The system I want operates sort of like Cron, with these exceptions:It should be function callback/micro-process oriented rather than shell oriented.Tasks should probably be executed in a delegate sub-process pool, or in-process of the daemon, rather than spawning a new process per task.It should have a resolution of 1 second (or smaller)The system I want also operates sort of like a message or task queue, with these exceptions:It should allow for periodic tasks (already possible in some queues, I think)It should support parallel execution for tasks that are scheduled for a given tick, rather than sequentially running them off a queueIt shouldn't expect tasks to be long-running, and shouldn't build its interface for long-running tasksIt should be just as easy to make recurring tasks as one-off tasks, without having to build task-chaining glueI should be able to cancel scheduled tasks easily and quicklyRobustness of preserving and guaranteeing task execution is not a priority over per-task overhead. Vertical and horizontal scalability is way more important than carefully preserving data (at this layer)Tasks should probably be able to share state at some level (so that IPC and task execution latency/overhead is minimized)If the system supports horizontal scaling, I should be able to give grouped tasks an affinity so that they are executed off the same shared state, rather than sent to an arbitrary worker in a poolMy preferred programming platform is python, but I would be fine with a stand-alone system in any language that allows for low-latency server side IPC over a standard protocol, so I can use my server-side language of choice. I'd also be fine with a system that specifically integrates with popular server-side languages, as my task implementations are likely to be a pretty small portion of my larger system.Having a built-in ability to optionally send events to clients in a push style would also be cool, but definitely does not have to be part of this library or layer.
System for scheduling parallel tasks/callbacks
design;architecture;libraries