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
I'm experimenting with the implementation of when_all and it appears that the future that is created is always a 'polling' implementation? Is it possible to get a non-polling implementation (all the future's I've passed in are continuable)?
Additionally - the when_all_future doesn't appear continuable without using the free function then.
I had implemented a similar construct in my own library in the past, but it required modifying the future being waited upon to have a list of dependants. Potentially a similar construct could be added by adding a continuation to the future to check if the when_all_future is ready yet on the inline executor?
Because the when_all_future is polling, if I execute > num_cpus of when_all futures, then they can consume all the active threads and cause a deadlock in the executor.
To reproduce - I wait on a set of when_alls that are in turn waiting on futures that have been created by then.
That means that the when_all polling task is queued before the task represented by the thens are queued - causing it to wait forever and fail to make progress.
I know you're busy - So I appreciate you may not have time to assist
All the best
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
-
I'm experimenting with the implementation of
when_all
and it appears that the future that is created is always a 'polling' implementation? Is it possible to get a non-polling implementation (all the future's I've passed in are continuable)?Additionally - the when_all_future doesn't appear continuable without using the free function
then
.I had implemented a similar construct in my own library in the past, but it required modifying the future being waited upon to have a list of dependants. Potentially a similar construct could be added by adding a continuation to the future to check if the when_all_future is ready yet on the inline executor?
Because the when_all_future is polling, if I execute
> num_cpus
of when_all futures, then they can consume all the active threads and cause a deadlock in the executor.To reproduce - I wait on a set of
when_all
s that are in turn waiting on futures that have been created bythen
.That means that the
when_all
polling task is queued before the task represented by thethen
s are queued - causing it to wait forever and fail to make progress.I know you're busy - So I appreciate you may not have time to assist
All the best
Beta Was this translation helpful? Give feedback.
All reactions