Open RalfKornmannEnvision opened 3 years ago
Suchiman
commented
3 years ago I remember stumbling upon this while hacking on the GC, specifically https://github.com/dotnet/corert/blob/a7ff563b560aa14e230f327e5529cfd255eaa116/src/Native/gc/unix/gcenv.unix.cpp#L1028-L1038 (which should be fixed as well) but i don't remember the exact reason. I thought i've read the priority cannot be changed after thread creation but that appears to be false.
RalfKornmannEnvision
commented
3 years ago I remember seeing this when porting to the Switch/PlayStation
The place I was refering to is here:
Edit: Did a quick check. BoostThreadPriority is currently only used by the server GC for the GC threads. But it should be possible to implment it for Unix. But as I currently don't run a server GC I cannot test it
Edit2: Did some more digging. It seems that in many cases the OS is configured in a way that a regular process cannot change the thread priority. Therefore properly nobody cared that much. A quick check in the mono and runtime source showed that both have the code to support it when the OS allows it. Therefore I think we should have it in the same way in CoreRT.
PS: while trying around a little bit i fixed this TODO // TODO: Figure out which scheduler to use, the default one doesn't seem to // support per thread priorities.
It still has the limitation that it will only work when the OS allows it but if not it will just do nothing which is the same as now. I can make a PR for it
jkotas
commented
3 years ago . It seems that in many cases the OS is configured in a way that a regular process cannot change the thread priority. Therefore properly nobody cared that much
Yes, that's correct.
It still has the limitation that it will only work when the OS allows it but if not it will just do nothing which is the same as now. I can make a PR for it
💯
As a game developer I like to have some control over the thread priorities.
I checked the code and it's not implemented, yet. Is there a reason beside nobody had the time yet? Based on the code there are two missing parts
Beside of converting the priorities the actual set and get functions should be pretty easy. The question here is only if the conversion should be done on the C# or C side?
The handle might be more tricky as pthread_t doesn't need to be a numeric type.
Therefore my idea is to store the handle in the managed part a a intptr. For systems that uses a numeric type for pthread_t that is smaller than a pointer we can just use it direct. On other systems we need to allocate some memory to store a copy of pthread_t and the managed part will store a pointer to this memory. But we need to make sure the memory is freed when the managed thread object is collected.
The other option would be doing it in the same way as socket addresses are store. The managed part asks the native how much space is needed. It creates a byte array and every time a native call is made the array is pinned. While this is very straight forward it might be less efficent. But I don't expect that many calls there.