- 23 Mar, 2023 1 commit
-
-
Tom Niget authored
-
- 20 Mar, 2023 1 commit
-
-
Tom Niget authored
-
- 19 Mar, 2023 1 commit
-
-
Tom Niget authored
-
- 16 Mar, 2023 1 commit
-
-
Tom Niget authored
-
- 14 Mar, 2023 2 commits
- 13 Mar, 2023 1 commit
-
-
Tom Niget authored
-
- 10 Mar, 2023 1 commit
-
-
Tom Niget authored
-
- 09 Mar, 2023 5 commits
- 08 Mar, 2023 5 commits
- 16 Aug, 2022 10 commits
-
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
- 12 Aug, 2022 6 commits
-
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
Previously, an exception thrown from a fork was rethrown: - a) when the call to fork() returns if the fork completes synchronously - b) otherwise, at the next explicit call to Sync() if there is one - c) otherwise, when the call to the enclosing Join coroutine returns In the case of infinite fork loops, this meant exceptions might never be propagated. Now, when an exception is thrown from a fork it's always rethrown when the call to the enclosing Join coroutine returns. The body of the Join coroutine just stops executing as soon as possible once a fork signals an exception. This will be at the call to fork() if the fork completes synchronously, or at any ensuing call to Sync() or fork() otherwise. Essentially once an exception is signaled from a parallel fork, the next call to fork() behaves like Sync() instead of creating a fork, and once all the parallel forks have completed, execution resumes directly at the call to the enclosing Join coroutine, where the exception is rethrown.
-
- 09 Aug, 2022 5 commits
-
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
Previously when forked tasks didn't finish synchronously, they were added to a list of children tasks and destroyed at the next sync. But this meant that in the case of an infinite loop spawning new forks, such memory could grow unboundedly and never be reclaimed. Fixing this also required changing how exceptions in forks are propagated.
-
- 08 Aug, 2022 1 commit
-
-
Xavier Thompson authored
-