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
In application where Polars share resources with other demanding functionalities, such as a tokio webserver, having two runtimes (one for web, one for Polars) feels like it would result to sub-optimal use of each runtime (if they are both constrained) or over-subscription (if they each have access to all os threads).
Would it make sense to allow setting Polars tokio runtime from user code?
Same reasoning applies to the rayon thread pool. It is my understanding that letting user provide the resources to algorithms in a library increase composability while reducing the burden on library developer to manage globals.
The text was updated successfully, but these errors were encountered:
Description
In application where Polars share resources with other demanding functionalities, such as a tokio webserver, having two runtimes (one for web, one for Polars) feels like it would result to sub-optimal use of each runtime (if they are both constrained) or over-subscription (if they each have access to all os threads).
Would it make sense to allow setting Polars tokio runtime from user code?
Same reasoning applies to the rayon thread pool. It is my understanding that letting user provide the resources to algorithms in a library increase composability while reducing the burden on library developer to manage globals.
The text was updated successfully, but these errors were encountered: