On Mon, 2020-01-20 at 22:47 +0800, Liu Hao wrote:
> 
> Sorry for the diction and misunderstanding. It will be really nice of
> you if you contribute, and we will appreciate your help.
> 
> To be precise: It was not being an extension that I dislike. What I
> dislike is that the `pthread_{get,set}_num_processors_np()` functions
> only care about the number of logical processors thus are unaware of
> processor groups. Things such as `pthread_{get,set}affinity_np()` on
> Linux would be much more satisfactory, which are good inspiration too.
> 

Thanks for clearing this up, and sorry for the misunderstanding.

I am thinking then to, instead of exposing processor groups directly, implement
`pthread_{get,set}affinity_np` and have `pthread_set_affinity_np` equivalent to 
the linux versions
where they work across all logical processors of the system regardless of 
physical processor as a
numbered set, `pthread_setaffinity_np` would then be responsible for 
mapping/setting the right
processor group etc. internally.

Applications would then only have to get the count of all logical processors, 
and give each worker
thread an affinity and utilisation of all cores would be possible. This would 
be sufficient for my
use case, and I imagine most others.

When time allows I'll work on a patch and come back to the list when reading. 
Thank you for the
feedback.

Regards,
Malcolm MacLeod



_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to