Hi John, Thanks a lot for your suggestion and offer to call/chat! I am going to look into the limiting_executor.
Kor On 9/2/20 11:07 AM, Biddiscombe, John A. wrote: > > Kor > > > Have a look at limiting_executor in the source (1.5 release only). It is > a replacement in some ways for the sliding_semaphore > > > The caveat is that the user must launch the work/tasks using the > limiting executor - if you want to allow the user to launch work using > another executor, but have it still capped/limited, then I'd need to > extend this somehow. There is an example in the async_mpi module that > uses the number of mpi tasks in flight to cap the task count, but it > hooks into the executor using a special customization - it might give > you ideas. > > > I'd be happy to chat about it if you have a specific use case and want > to zoom call me sometime. > > > JB > > > > -- > Dr. John Biddiscombe, email:biddisco @.at.@ cscs.ch > http://www.cscs.ch/ > CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 > Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82 > ------------------------------------------------------------------------ > *From:* hpx-users-boun...@stellar-group.org > <hpx-users-boun...@stellar-group.org> on behalf of Kor de Jong > <k.dejo...@uu.nl> > *Sent:* 02 September 2020 10:57:17 > *To:* hpx-users@stellar-group.org > *Subject:* [hpx-users] Limiting the speed with which tasks are created > Hi list, > > I have a question about limiting the speed with which tasks are created: > > What are the options to limit the speed with which tasks are generated, > without having access to futures representing one or more task trees? > > I develop a set of algorithms that create tasks. Other people will be > using these algorithms. Ideally, I would like to also offer a hook to > set a maximum tree depth. But, ideally, I have no information about the > task trees created by the user's code. I do not have access to the > futures representing these. > > I currently use a sliding semaphore in combination with a (too) special > future representing a user's task tree. This works, but is not flexible > enough. It cannot handle the situation of having multiple task trees, > for example. Also, the user now needs to decide on which future is the > root of the task tree. I would prefer the user to only have to think > about which algorithms to call and not about task trees and dependencies > between tasks. > > I offer the user a framework to simulate processes iteratively through > time using time steps. My algorithms are intended to be called per time > step. The maximum tree depth in my use case is typically expressed as > the maximum number of time steps for which task are created. The > iteration through time is part of my library code. I know nothing about > which of the algorithms are actually called and in which order. > > I can imagine that what I need is not possible / very hard to achieve, > but maybe I am wrong? > > Thanks in advance for any hints! > > Kor > _______________________________________________ > hpx-users mailing list > hpx-users@stellar-group.org > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users > <https://mail.cct.lsu.edu/mailman/listinfo/hpx-users> > > _______________________________________________ > hpx-users mailing list > hpx-users@stellar-group.org > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users > _______________________________________________ hpx-users mailing list hpx-users@stellar-group.org https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
