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 ForkJoinPool.ManagedBlocker API is clunky and has performance issues. It would be really nice if the wiring framework could implement back pressure (and other blocking operations) without use of a managed blocker.
As an alternative, I propose creating a mechanism that would allow a sequential task to increase the dependency count of the next awaiting in the logical queue. Something along the lines of send(-1). Then, instead of blocking while waiting to insert a thing into the next step in the pipeline, create a new fork join task that will re-attempt insertion and will call send() on the next task if successful. If not successful, the new task would schedule another task to retry, and so on.
The text was updated successfully, but these errors were encountered:
The
ForkJoinPool.ManagedBlocker
API is clunky and has performance issues. It would be really nice if the wiring framework could implement back pressure (and other blocking operations) without use of a managed blocker.As an alternative, I propose creating a mechanism that would allow a sequential task to increase the dependency count of the next awaiting in the logical queue. Something along the lines of
send(-1)
. Then, instead of blocking while waiting to insert a thing into the next step in the pipeline, create a new fork join task that will re-attempt insertion and will callsend()
on the next task if successful. If not successful, the new task would schedule another task to retry, and so on.The text was updated successfully, but these errors were encountered: