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
Within a single expression, future::then is frequently used multiple times with relatively fast pieces of code that do not justify the overhead of yielding control to the event loop. This anti-pattern is present in examples within stlab's documentation and is pervasive in actual usage. The extensive usage is likely due to an enhanced clarity of the resulting code.
This task is to come up with a mitigation strategy for this anti-pattern.
Acceptance criteria
A mitigation strategy has consensus within the stlab team
The mitigation strategy is executed
Possible solutions
Modify documentation to warn against this kind of usage
Incorporate ideas from the Sender/Receiver model which mitigates this by separating task execution from task graph building
The text was updated successfully, but these errors were encountered:
I see your point.
I use this pattern often to decouple file I/O from the UI, which makes sense from my point of view.
I think it would be good to give the user a hint of how big the task should be that is handled within a single continuation.
Within a single expression,
future::then
is frequently used multiple times with relatively fast pieces of code that do not justify the overhead of yielding control to the event loop. This anti-pattern is present in examples within stlab's documentation and is pervasive in actual usage. The extensive usage is likely due to an enhanced clarity of the resulting code.This task is to come up with a mitigation strategy for this anti-pattern.
Acceptance criteria
Possible solutions
The text was updated successfully, but these errors were encountered: