3 ms·
Also, it looks like there's a getter for the "current" task (https://socketry.github.io/async/guides/getting-started/index.html#nested-tasks https://socketry.gi
by derefr 5y ago
Also, it looks like there's a getter for the "current" task (https://socketry.github.io/async/guides/getting-started/index.html#nested-tasks https://socketry.github.io/async/guides/getting-started/inde...), sort of like Thread.current.
Which means that you can just write a whole normal Ruby program, that just uses Task::Async.current.async(...) wherever it likes to schedule subtasks (sort of like calling spawn/3 in Erlang), and then treat them as regular futures, even returning the future out of the current lexical scope without thunking it; and then have exactly one Async block at the toplevel that kicks off your main driver logic and then #wait s on it. All without having to pass the current task down the call stack everywhere.
(And if you want to schedule a bunch of stuff to happen in parallel and then wait for it all to be done, but you're below the toplevel Async block, you'd do that by scheduling the subtasks against an Async::Barrier: https://socketry.github.io/async/guides/getting-started/index.html#waiting-for-multiple-tasks https://socketry.github.io/async/guides/getting-started/inde...)
- brunosutic 5y ago> Which means that you can just write a whole normal Ruby program, that just uses Task::Async.current.async(...) > All without having to pass the current task down the call stack everywhere. Yes, you can also use `Async { work }` instead of `Async::Task.current.async { work }`.