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
Right now we type erase the input and output future that we send to our custom executor closure by wrapping everything in a cancellable oneshot channel.
This is the simplest API for callers and generally a reasonable default. But, there are use cases that might benefit from preserving some type information.
For instance: Perhaps there are multiple future types, and some should be weighted heavier for acquiring concurrency permits.
One initial thought is, expose a Any<PhantomData<T>> input into the closure, where T is the output type of the input future. Maybe via an alternate setting of the existing executor.
There might also be benefit in another 'turnkey' strategy that allows selecting between multiple other strategies based on input future type, rather than requiring the full fledged custom executor?
The text was updated successfully, but these errors were encountered:
jlizen
changed the title
Feature: Propagate future output type into custom executor
Feature: Propagate future output type into custom executor closure
Dec 24, 2024
jlizen
changed the title
Feature: Propagate future output type into custom executor closure
Feature: Propagate output type into custom executor closure
Dec 26, 2024
Right now we type erase the input and output future that we send to our custom executor closure by wrapping everything in a cancellable oneshot channel.
This is the simplest API for callers and generally a reasonable default. But, there are use cases that might benefit from preserving some type information.
For instance: Perhaps there are multiple future types, and some should be weighted heavier for acquiring concurrency permits.
One initial thought is, expose a
Any<PhantomData<T>>
input into the closure, whereT
is the output type of the input future. Maybe via an alternate setting of the existing executor.There might also be benefit in another 'turnkey' strategy that allows selecting between multiple other strategies based on input future type, rather than requiring the full fledged custom executor?
The text was updated successfully, but these errors were encountered: