You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The parallel macro is used to run pieces of code concurrently. Ideally, it waits for all fibers to finish and returns the combined return values of all jobs.
However, when one fiber raises, the exception is raised in the enclosing context which means it will immediately resume execution. This breaks the waiting connection to the other concurrent fibers and send calls to the collector channel block indeterminately. This makes them zombie fibers.
There is no optimal strategy for all use cases, but IMO it would be a better solution to remember the exception but wait for the other fibers to complete and only raise it afterwards. This makes sure that all tasks are properly finished and only raises when execution is to continue in the parent context.
We introduced parallel just for fun, to see if we could make it work. In my opinion we should remove all these quick features (parallel, future, etc.), rethink them, then reintroduce them.
The
parallel
macro is used to run pieces of code concurrently. Ideally, it waits for all fibers to finish and returns the combined return values of all jobs.However, when one fiber raises, the exception is raised in the enclosing context which means it will immediately resume execution. This breaks the waiting connection to the other concurrent fibers and
send
calls to the collector channel block indeterminately. This makes them zombie fibers.There is no optimal strategy for all use cases, but IMO it would be a better solution to remember the exception but wait for the other fibers to complete and only raise it afterwards. This makes sure that all tasks are properly finished and only raises when execution is to continue in the parent context.
Related to #6468
The text was updated successfully, but these errors were encountered: