Incorrect calculation oss priorities for posix threads

[mdavidsaver]

For the posix implementation of osdThread the mapping of epics priorities to OS priorities uses sched_get_priority_max. However, the value returned does not reflect any current administrative limits which may be in place (eg. /etc/security/limits.conf).

Currently trying to set a priority which is higher then allowed leaves the priority at the current level (default 0). This can lead to a situation where low priority threads (eg errlog) have a higher priority then the scan and callback threads.

[Till Straumann (strauman)]

The described behavior was observed under linux -- it does not necessarily apply to other posix systems

[Till Straumann (strauman)]

The existing code determines the available priority range once and caches the return values of sched_get_priority_min()/sched_get_priority_max().

The proposed fix (implemented by the patch) creates a helper thread (this happens only a single time, i.e., when the the epicsThreads facility is initialized) which takes the above min/max values as a starting point for a binary search for the maximal priority that can be set on the system.

[Till Straumann (strauman)]

Unfortunately, the previously submitted patch had a flaw:
When an EPICS process was started intentionally
w/o real-time privileges (e.g., a CA client, tool or the like)
a warning message

sched_get_priority_max failed set to 0
sched_get_priority_min failed set to 0

would pop up.

This new version of the patch fixes this and restores
old semantics:

- process has no RT privileges: priority range is silently set to 1..1
  (this lets epicsThreadCreate detect that it doesn't have permission
  to use the RT scheduler)
- process has no RT privileges but sched_get_priority_max()/_min()
  fail: above warning shows
- process has RT privilege: compute available priority range (under
  resource limit constraints).

[Till Straumann (strauman)]

Here is a differential patch that can be applied over the original one
(which has been removed from this page; the differential patch is
intended for maintainers who already applied the original patch).