bug#14756: threads - par-map - multicore issue

[Ludovic Courtès]

Andy Wingo <address@hidden> skribis:

> I see this, but I'm not quite sure what's going on.  What I do see is
> that par-map of 1+ on a list is horribly slow, both on 2.0 and master.
> Ludovic do you know what's going on here?

As David put it, only one core is being used, which is clearly a bug.

I believe the bug was introduced by
8a177d316c0062afe74f9a761ef460e297435e59 (however, before that commit,
you would hit a stack overflow when doing ‘par-map’ on a large-enough
list.)

What happens is that ‘par-mapper’ creates nested futures whose
dependency graph forms a comb-shaped tree; thus we quickly hit
%MAX-NESTING-LEVEL.

This is fine in itself, but for some reason, it ends up evaluating most
of those futures in one thread while the other threads apparently remain
stuck in ‘wait-condition-variable’ in ‘process-futures’.

I’ve looked into it a bit but that needs more time…

Ludo’.