Re: Help: Ada in NetBSD

[Fernando Oleo Blanco <irvise_ml@irvise.xyz>]

Okay, so another short blog post. This is going to be a bit of a fucking 
rant.

So... remember when I said that NetBSD expected a priority value of -1 
when using SCHED_ODER? And that that was not POSIX compilant? Well, 
after a nice conversation in #netbsd, it has been decided to escalate 
this matter into a PR/ML discussion. All that good :)

But the question on how does Linux work then? Remained... So I ran the 
ACATS suite with debugging symbols, recompilation and assertions to 
check. And guess what?

Let the code speak:


    else 

      Param.sched_priority := 0; 

      Result := 

      pthread_setschedparam 

      (T.Common.LL.Thread, 

       SCHED_OTHER, Param'Access); 

    end if; 


    pragma Assert (Result in 0 | EPERM | EINVAL); 

end Set_Priority;

So the Set_Priority function receives the Default_Priority value, which 
I think was 48. But when it goes into the actual branch, it knows that 
that default value is stupid and discards it (sets it to 0). That would 
be all nice and dandy, but here is the problem, 0 is a valid value 
because most OS/arches use it, there is no reason 0 is valid (as per POSIX).

And what really gets me is that Pragma... Whomever wrote it probably was 
getting errors and decided that that was fine. EPERM? EINVAL? Not my 
problem! No wonder there is a specific s-taprop__linux.adb...


So here we are. NetBSD is not POSIX compliant (min and max SCHED_OTHER 
priority is -1, which is an error code for the function that should 
return it), and Linux hardcodes it. Amazing, just amazing...


My solution? Email the NetBSD people. But that won't be enough. So I am 
thinking in patching the s-taprop__posix.adb file to try it with the 
default priority, if it fails, with 0, if it fails, with -1 for NetBSD...


Oh well... I thought that the state of GNAT was better... Anyhow, regards,
-- 
Fernando Oleo Blanco
https://irvise.xyz