This is a partial fix of a WIN32-only problem Mark Rivers reported.
A WIN32 thread created by a manufacturer's library is used to call one
of his callback routines, which tries to use an epics facility that has
an epicsThreadOnce(). The new version of epicsThreadOnce() uses
epicsThreadGetIdSelf() to detect recursive initialization; the thread
doesn't have an epicsThreadId yet, so epicsThreadImplicitCreate() is
asked to make one. It calls epicsThreadGetOsiPriorityValue(), but
osdPriority is 15 which is not known by that code, so it reports an
error by calling errlogPrintf(). That checks epicsThreadIsOkToBlock()
which calls epicsThreadOnce() but that needs our epicsThreadId...
This doesn't solve the issue of the unknown osdPriority value 15
(priorityClass = 32), but it allows the IOC to continue working with
just a warning message at init time.
It also points out that calling epicsThreadGetIdSelf() every time we
check an epicsThreadOnce() is probably not good for performance.
An epicsThreadOnceId is now an epicsThreadId.
During initialization, it is set to the thread running the init routine
which can now detect a recursive initialization attempt and suspend.
EPICS_THREAD_ONCE_INIT is still zero, the implementations now define a
new private value for EPICS_THREAD_ONCE_DONE. This is deliberately not
made public.
(not a bug but messy)
o added optimization where we only check as many registered fd's
on the list as select tells us are active in its status
o added code to clear all of the fd_set if select returns an error
(in practice this would not cause a bug other than some extra activity
that would immediately self terminate when it clear the flag in the fd_set,
and also we dont see the error message printed when select returns an error)
Apparently the GeSys dynamic linker doesn't maintain C semantics.
I'm afraid that this behaviour is likely to cause lots of other problems,
but for now I'll apply the patch since it's harmless.
Nick Rees