Is it necessary to differentiate it by name? I think that the overload alternative is quite good and user won't have to choose constantly between "singular" and "plural" functions. Even if the vector with a single element is passed, we can forward it to the old set_core_type(core_type_id) function.

A possible way of handling conflicting max_concurrency or max_threads_per_core can be interpreting each constraint instance as an independent constraint with its own max_concurrency and max_threads_per_core. Once affinity mask is determined for each constraint, the union of them is created, so the sum of max_concurrency-ies, which can be used the overall max_concurrency for result task_arena instance.

max_threads_per_core is not needed to be handled anyhow specifically as it is directly reflected in the mask of the constraint.

I asked a similar question in PR1926 but it applies here too. Assume there is a system with three core types, indexes 0, 1 and 2 and there are 4 of each kind. What if the user wants 6 slots and to use the most performant cores. From what you describe, I think they would create a constraint for index 2 and max_concurrency of 4 slots. And then another for index 1 and max_concurrency of 2? Is that right? The result would be a max_concurrency of six and a mask that includes both index 2 and index 1 core types? So if all core types are idle, the arena may populate with 4 index 1 types and 2 index 2 types, or 2 index 1 types and 4 index 2 types, right? Would one be expected over the other?

I have removed this from the cons. If we adopt this alternative, the new behavior will be part of the proposal.

@vossmjp I think in this case the only possible way to populate arena would be with 4 index 2 and 2 index 1 threads, since user has specified such constraints that result in the mask that maps threads joining the arena to 4 P-cores and 2 E-cores.

But you would need to pick which e-cores are in the mask.

Yeah, I understand your question now. It seems we can try applying the same approach we are using right now, which is "Let the OS decide". Currently, if the user specifies 2 threads as max_concurrency for the arena constrained to E-cores on the platform which has, let's say, 10 of them, the mask will be created for all these 10 e-cores, right? But only two threads will join the arena and has their affinity set to the mask.
I guess with multiple constraints, arena should apply the mask per constraint. For the example you described above, first four threads joining the arena will have affinity of the P-cores, while the last two threads will be assigned E-cores mask.

Or simply extend the current logic - do not make any preference for what cores to populate first. That is, use the united mask that will include all P-cores and all E-cores, and let the system decide on the threads migration.