Comment 3 for bug 1816841

Thanks Till,

I'll apply that for my RTESM5 port too and test it.
(Meanwhile I use the posix osdTthread variant also for RTEMS5).

If "we" are already there, the following call has been causing problems for a long time.

- pthreadInfo = init_threadInfo("_main_",0,epicsThreadGetStackSize(epicsThreadStackSmall),0,0);
+ pthreadInfo = init_threadInfo("_main_",0,0,0);

So that the "ur-task" is started, during POSIX_Init. But as non Epics-task it gets the OSI-prio "0".
Shouldn't something like IocShPrio 91 be set here?

Unfortunately I can't set it in rtems_init with epicsThreadSetPriority because it is a
non-epics-task.

But in some tests we read the epicsPrio from this thread (and you get it back as 0) and then e.g. in the ringPointerTest.c we create some threads with the prio 0 and 1 ;-)
Then they hang ...

"ringPointerTest.c" line 171 of 248

static void testPair(int locked)
{
    unsigned int myprio = epicsThreadGetPrioritySelf(), consumerprio;
    pairPvt pvt;

...
testDiag("single producer, single consumer with%s locking", locked?"":"out");

    /* give the consumer thread a slightly higher priority so that
     * it can preempt us on RTOS targets. On non-RTOS targets
     * we expect to be preempted at some random time
     */
    if(!epicsThreadLowestPriorityLevelAbove(myprio, &consumerprio))
        testAbort("Can't run test from thread with highest priority");

    epicsThreadMustCreate("pair", consumerprio,
                          epicsThreadGetStackSize(epicsThreadStackSmall),
                          &pairConsumer, &pvt);
    /* wait for worker to start */
    epicsEventMustWait(pvt.sync);