| Type | Intent | Optional | Attributes | Name | ||
|---|---|---|---|---|---|---|
| type(sort_key_buf), | intent(in) | :: | keys(:) |
the keys, in precedence order. |
||
| integer(kind=int64), | intent(in) | :: | n |
rows to order. |
||
| integer(kind=int64), | intent(in) | :: | nthreads |
resolved thread count; 1 sorts serially. |
||
| integer(kind=int64), | intent(inout) | :: | perm(:) |
receives |
THE engine entry point when a thread count is available -- Stage 4.
Answers bit-identically to sort_build_permutation at every thread count, and
that is a property of the ordering rather than of the implementation: sort_row_less
ends in a row-index tiebreaker, so no two distinct rows compare equal, exactly one
permutation is correct, and every correct algorithm must produce it. A threading bug
therefore shows up as a WRONG permutation, never as a differently-ordered valid one.
nthreads is a resolved count, never a sentinel -- resolve_thread_count has already
applied the caller's threads=, the automatic policy and the in-parallel rule. This
procedure applies only the two clauses that need the DATA to decide: the row floor
(an internal team-scaled rule), below which a team costs more than it saves,
and one thread meaning the plain serial path. Both are observable through
parquet_debug_sort_threads_used, which is the only way a test can see either.