Asynchronicity and Threading
By default Trial will run two threads: the main thread, which is initiated via
launch-with-context and controlled by the context, and the separate render-thread, initiated by the
render-loop. These threads are kept separate so that the main thread can always respond to window events and inputs and schedule them up as fast as possible, preventing the application from appearing as locked up even if the render thread might be busy for a spell, such as with a loading operation.
However, this still means that by default, for all intents and purposes, your game will run single-threaded, with all steps happening on the render thread. This is fine for most things, but especially long-running operations like network requests or long saves and loads could cause stutters or hangups in the UI. In this case you may want to keep a separate back thread to perform such long-running operations.
Trial offers a very simple system based on the simple-tasks and promise libraries. Simply have your
main class inherit from
task-runner-main, and then schedule tasks on the back thread via
with-eval-in-task-thread. You can also use
simple-tasks:schedule-task with a function object and the
Both will return a
promise object so that you can chain the operation and keep track of the result value or failure state. See the promise library above for more information on how to use the promises.
Some operations will also require the reverse: running stuff in the render loop. You can do this with
with-eval-in-render-loop. This macro can also be very useful for REPL interaction while the game is running, as then you can simple compile a form like that in, and have it run synchronously on the render thread, avoiding issues with asynchronous resource interaction.