Regression with concurrent_maplist/3 in 8.3.27?

Help! Predicate
1

On my mac (10.15.7 - Catalina) running Swi-Prolog (8.3.27), I have a problem with concurrent_maplist/3 not terminating even after 12 hours of processing

 cache(Cache, U):-
	phrase(inventory, L)
%	, maplist(file_index, L, U)
	, concurrent_maplist(file_index, L, U)
	.

file_index(Dir-f(Item, Path, Hash, Size, Time), Hash-u(Dir, f(Item, Path, Hash, Size, Time))):-!, crypto_file_hash(Path, Hash, [encoding(octet), algorithm(md5)]).
file_index(Dir-d(Item, Path, Hash), Hash-u(Dir, d(Item, Path))).

time(cache(_, _)).

Essentially, inventory//0 returns a list of files and directories (ca 7.000), for which I want to compute a hash.
Using the same routine with maplist/3 finishes as expected after ca 400 seconds.
Is there anything I am doing wrong with concurrent_maplist?

N.B. Running the same code with swipl 8.2.4 works like a charm.

2

Looks like a bug. concurrent_maplist/3 hasn’t been changed in ages. I guess it is in some sort of deadlock. First step would be to use Control-C and then ‘b’ (break) to get a new toplevel and then threads/0 to see the state of all threads. If that doesn’t reveal anything one may need the C level debugger to see what is happening.

If it worked for 8.2.4 it is most likely just luck and there is some timing or concurrency issue.

3

I checked as per your suggestion. Me seems that concurrent_maplist’s main process processes all list elements, then closes all threads but itself, and then just stays around eating CPU

[1]  ?- threads.
% Thread Status       Time    Stack use    allocated
% --------------------------------------------------
%   main running     0.339    2,845,984    4,577,088
%     gc running     6.496        1,216       87,872
%      6 running   158.451      493,480      677,696
%      7 running   160.207      100,192      350,016
true.
4

running doesn’t mean it is eating CPU. It just means it is not terminated somehow. The (portable) thread API doesn’t allow to figure out whether a thread is actually running or waiting for something. You way wish to use OS tools to find out whether it is using CPU. Looks like not, considering the times.

You can get some more info using ?- debug(concurrent). and check the source code to see what it all means. From the break environment you can also use tbacktrace/1,2 to try and find out what the threads are doing.

Others can only do something if we can reproduce this …