On Fri, 10 Jan 2020 01:43:18 +0100 Zelphir Kaltstahl <zelphirkaltst...@posteo.de> wrote: > Hi Chris! > > On 1/8/20 12:44 PM, Chris Vine wrote: > > On Wed, 8 Jan 2020 08:56:11 +0100 > > Zelphir Kaltstahl <zelphirkaltst...@posteo.de> wrote: > > [snip] > >> So my questions are: > >> > >> - Is there a default / recommended way to limit parallelism for > >> recursive calls to parallel forms? > >> > >> - Is there a better way than a global counter with locking, to limit the > >> number of futures created during recursive calls? I would dislike very > >> much to have to do something like global state + mutex. > >> > >> - What do you recommend in general to solve this? > > I think you have it wrong, and that futures use a global queue and a > > global set of worker threads. I don't see how futures could work > > without at least a global set of worker threads. Have a look at the > > futures source code. > > So far I did not write any parallel code in my project. I am only > exploring possibilities, finding out what I should be using. I also > could not think of a good way to limit the number of threads to anything > less than the (current-processor-count) value, but thought maybe someone > knows something I did not see or read about Guile's futures yet : )
I still don't understand why you think you want to do that, given the aims you set out in your earlier posts. Why do you want to spawn less than (processor-count - 1) threads for your algorithm, which is what futures would use? But if you really want to do that, and you don't want to use a stand-alone thread pool, the parallelism keyword of fibers seems to do what you want.