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
Is your feature request related to a problem? Please describe.
Currently, CurlApiCallbacks.c which is an implementation of the API callback provider drives the liveness via dedicated threads. This leads to cases where for each upload handle we issue a single network thread. As there could be cases where there could be multiple parallel upload handles (some not-yet active while others err-ed out and needed to be collected) we would temporarily increase the work-set size. The problem is more evident when we have a pogo-stick effect of creating and deleting sessions in case of latency pressures and not immediately recovering.
Describe the solution you'd like
Provide liveness for the network not via individual threads but rather a thread pool.
Describe alternatives you've considered
An alternative and perhaps a better solution that we should move towards is a vat system - or task based system where the tasks would be enqueued and executed by a liveness unit which could be a flexible thread pool.
Additional context
Add any other context or screenshots about the feature request here.
This discussion was converted from issue #172 on February 23, 2023 00:28.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Is your feature request related to a problem? Please describe.
Currently, CurlApiCallbacks.c which is an implementation of the API callback provider drives the liveness via dedicated threads. This leads to cases where for each upload handle we issue a single network thread. As there could be cases where there could be multiple parallel upload handles (some not-yet active while others err-ed out and needed to be collected) we would temporarily increase the work-set size. The problem is more evident when we have a pogo-stick effect of creating and deleting sessions in case of latency pressures and not immediately recovering.
Describe the solution you'd like
Provide liveness for the network not via individual threads but rather a thread pool.
Describe alternatives you've considered
An alternative and perhaps a better solution that we should move towards is a vat system - or task based system where the tasks would be enqueued and executed by a liveness unit which could be a flexible thread pool.
Additional context
Add any other context or screenshots about the feature request here.
Beta Was this translation helpful? Give feedback.
All reactions