From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,93db2bcd4637d4fc X-Google-Attributes: gid103376,public From: Simon Wright Subject: Re: Runtime Error with gnat 3.10p Date: 1998/05/26 Message-ID: #1/1 X-Deja-AN: 357202839 References: <6kel87$ic7$1@polo.advicom.net> X-NNTP-Posting-Host: pogner.demon.co.uk:158.152.70.98 X-Complaints-To: abuse@demon.net X-Trace: news.demon.co.uk 896331524 nnrp-05:9416 NO-IDENT pogner.demon.co.uk:158.152.70.98 Organization: At Home Newsgroups: comp.lang.ada Date: 1998-05-26T00:00:00+00:00 List-Id: "David C. Hoos, Sr." writes: > Andreas Jungmaier wrote in message ... > >Hello all, > > > >does anyone have an idea what the following little message is > >about : > >Failed Runtime Assertion : GNULLI failure---Set_Priority > > > >Note that this showed up after executing a compiled Ada program > >containing several tasks (instantiated task types) > >This is on RedHat-Linux. Could this have to do with the thread > >libs coming with gnat ? > Yes, it does. > One of the runtimes requires root privileges to do tasking while the > other does not (I forget which is which). Actually, the native threads requires root privileges to do *Annex D tasking* (as noted by Markus Kuhn). The relevant code in s-taprop.adb (3.11a1) is procedure Set_Priority (T : Task_ID; Prio : System.Any_Priority) is Result : Interfaces.C.int; Param : aliased struct_sched_param; begin T.LL.Current_Priority := Interfaces.C.int (Prio); Param.sched_priority := Interfaces.C.int (Prio); Result := pthread_setschedparam (T.LL.Thread, SCHED_FIFO, Param'Access); pragma Assert (Result = 0 or else Shutdown ("GNULLI failure---Set_Priority")); end Set_Priority; You would have thought this would result in an error for non-root users, cos (libpthread-0.71) pthread_setschedparam() calls __sched_setscheduler(), which is a system call not defined in libc5, but is in (linux/kernel/sched.c 2.0.33) which says if ((policy == SCHED_FIFO || policy == SCHED_RR) && !suser()) return -EPERM; but here it seems to work just fine. Hmm. Perhaps when I get round to upgrading to glibc ...