VxWorks does not mark abort() or exit() as noreturn.
Thus, functions declared noreturn which end in a call
to those functions cause a compiler warning on vxWorks.
Move isOkToBlock tracking to osdThread.
Targets except vxworks can store this flag in epicsThreadOSD.
Continue to use TLS w/ vxWorks.
Note that setting of isOkToBlock for "main" thread becomes lazy.
This flag causes EPICS to call abort() on assertion failures rather than
suspend the executing thread. With the epicsThreadSuspendSelf() behavior,
an IOC can end up in a difficult to detect error state where one or more
threads has essentially crashed due to an assertion failure.
This also matches the C behavior of assert(3)
Save/restore dbAddr::pfield around callbacks to
avoid corruption if CB forgets to restore.
Need to peak at dbChannel.h during libCom build.
So generate dbCoreAPI.h early, and add extra
-I to source location when compiling dbTrapWrite.c
Besides being deprecated in C++11 and removed in C++17, the intended use
case for this was always wrong, since std::unexpected() is called by the
C++ runtime when a function throws an exception that was not specified
in its "dynamic exception specification", which is different from an
exception thrown by user code which wasn't caught [1,2]. Using abort()
keeps the same behavior, but with the intended semantics.
We don't use std::abort() to simplify backwards compatibility.
[1] https://github.com/epics-base/epics-base/issues/343
[2] https://en.cppreference.com/w/cpp/error/unexpected
The call to setThreadName() is moved to avoid a race condition that
can happen with very short lived processes. If the process terminates
very quickly e.g. is a google test runner or the msi.exe command
called from a Makefile during a build, then very occasionally a
crash can occur during process termination if setThreadName() when called
from the newly created thread. This looks to be becauae the DLL it is
trying to call gets unloaded between it getting a handle to the DLL
and making the call. Moving the setThreadName() call to the creating
thread avoids this problem. The issue was only ever seen with statically
linked epics executables, I am unsure if the way a DLL based epics
program unloads might avoid this, or just make it less likely but
still possible. As mentioned above, the issue will only ever occur
to threads that are created during process termination and so would
not affect running IOCs
This was acomplished by making errSymbolAdd add the error symbol directly
into the global hash table and removing errnumlist which is not needed
anymore.
Unit tests were added for checking the following cases:
- Adding a valid symbol and checking that it exists (fixed by this change)
- Getting an existing error symbol
- Getting a non existing error symbol
- Adding an invalid error symbol (fixed by this change)
- Adding an error symbol with a code that already
exists (fixed by this change)
Therefore, issue #268 was fixed
error: statically allocate error symbol hash table
This will allow calling errSymbolAdd before errSymBld, therefore, a
function adding error symbols can now be run before iocInit or errlogInit
error: add a constant for the minimum module number
Make adding an identical error symbol not fail
A test case was also added which test that adding an error symbol
with same error code and message as one added before will not fail
Add locking to error symbol table
This protects the cases of:
- simultaneously adding and requesting of an error symbol
- simultaneously adding many error symbols
Update release notes regarding adding error symbols
