Per the manpage in the file's comment, SIOCOUTQ is equivalent to the
TIOCOUTQ ioctl, whose value can be obtained by including <sys/ioctl.h>,
which allows us to avoid including any system-specific headers. This is
desirable so that, on a musl system, it won't be necessary to install
kernel headers in order to build epics-base.
Since it's first been checked into Git, the Linux kernel has defined
SIOCOUTQ to be TIOCOUTQ [1].
From the three main libc options on Linux: glibc and uclibc use the
kernel headers, so both ioctls are available; and musl defines only
TIOCOUTQ in their own headers.
[1] https://github.com/torvalds/linux/commit/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
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)
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
Adjust macros for compiling for older MSVC/Win SDK versions
Try to cover missing fibres include in 7.0 SDK
Support Windows XP and above.
Also removed explicit define of _WIN32_WINNT in code if it has not
been passed on compile line. This is possibly a matter for
further discussion
Use ipcom_ipd_kill() to do it properly, announce when doing it.
Suspending the ipsntps task is dangerous, can hang the OS so
don't try to kill it if user already suspended the task.
Also drops checks for the "ipntpd" thread, not used.
Distinguish between IOC's clock sync thread and OS's one.
Show our sync interval even when not synchronized.
Only mention the clock sync thread where there can be one.
Group the private variables, note which are mutex-protected.
Reset the sync interval to 1 second if sync is restarted.
Initialize the syncFromPriority variable.
ClockTime_Init and ClockTime_Shutdown are only on VxWorks & RTEMS.
Adjust help text to match.
ClockTime_Init can be re-run later to start or stop the sync thread.
Érico Nogueira
zimoch