Here is my attempt at fixing #156. I've been thinking a bit about this issue and I agree that the behaviour isn't what one would expect. So here is my try at making sure the body of let-flow isn't using the last deferred thread. From what I understand of commit 193f5f48972c8e20dd0a9fc41a1311566a9f7bdd that was the intended goal.
Let-flow body should not be executed within the last deferred thread as it may exhaust a thread pool if the body computation is extensive. This commit ensures that the body is executed either within the executor specified through with-executor or on the default execute-pool.
I confirm this fixes the issue I ran into, and from a first glance should not introduce new complexity (at the expense of a few more objects due to onto).
Here is my attempt at fixing #156. I've been thinking a bit about this issue and I agree that the behaviour isn't what one would expect. So here is my try at making sure the body of let-flow isn't using the last deferred thread. From what I understand of commit 193f5f48972c8e20dd0a9fc41a1311566a9f7bdd that was the intended goal.
Let-flow body should not be executed within the last deferred thread as it may exhaust a thread pool if the body computation is extensive. This commit ensures that the body is executed either within the executor specified through with-executor or on the default execute-pool.