When I switched from merge to rebase of RTEMS5 changes, I think this
file didn't get merge correctly. These changes bring the file back to
match what was originally merged, and I believe correct.
RTEMS 5.x moved the PC BSP to 686. This commit makes the EPICS
target match; RTEMS-pc386 and the -qemu variant can only be built
when RTEMS_VERSION != 5, whereas RTEMS-pc686 and its -qemu version
will only build when RTEMS_VERSION == 5 (there are checks with
descriptive errors included).
makeTestFile.pl was also reformatted and modified to use exec to
run tests on non-Windows hosts as required by the Perl test harness.
If a test program reports test failures, the Perl wrapper
must return the same error status. On Windows where we use
system() instead of exec() that needs some value fiddling.
Creates a file .taps-failed in each O.<arch> directory,
appending the name of each tapfile that has failures to it.
The testFailures script now reads the .taps-failed files
from each directory listed in .tests-failed and nicely
displays the failing tests listed in each.
Records with lower PHAS value than any previously loaded records
were inserted at the end of the list rather than at the beginning.
This fixes lp: #1899697. Also fixes a proto-bug in that the second
argument to the previously used ellAdd() call assumed that
offsetof(scan_element, node)==0.
Thanks to Bruno Martins for providing this patch.
In some cases the license-identification header was missing,
so I added that as well. Replaced the remaining headers that
specifically identified "Versions 3.13.7 and higher".
Makefiles and the build system were deliberately excluded.
This is needed when convertRelease.pl gets run before the
EPICS::Path and EPICS::Release modules are installed, and
after 'make uninstall' has deleted the lib/perl directory.
Instead of displaying the failures from each submodule at the end
of testing that submodule, RULES_TOP suppresses the output when
it detects a parent module, and RULES_MODULES adds the children's
failure lists into the parent's list so they all get shown at the
end of the tests/results.
Add documentation for aSub from wiki.
Fix incorrect document structures.
Remove inclusion of menu.dbd files.
Fix links to common doc's, remove some links to nowhere.
Adjust podToHtml.pl and the rule that calls it.
If fastReceiver() took more than 0.01 seconds to exit,
sleepySender() might have pushed a second message onto
the queue after setting recvExit, so there would be an
extra message in the queue for the next test, which I
was seeing on Appveyor. That's my current theory...
The internal mySend() and myReceive() routines do expect a timeout
of -1 to mean wait forever, see the epicsMessageQueueSend() and
epicsMessageQueueReceive() API routines.
Move the code that wakes up the next sending task to after we've
added our threadNode to the receiveQueue. He still has to wait for
us to release the Mutex though, so this might make no difference.
This commit also changes when we decrement the number of waiting
senders so it always happens immediately after a threadNode gets
taken off the sendQueue by the code that removed it.
When sending a message, if the queue is full so we have to wait, we
create a threadNode with an eventNode in it and stick it on the
sendQueue, then wait for a receiver to signal that event, waking us.
If we awoke due to a timeout but a receiver was actually waking us
up anyway (i.e. eventSent was set), we shouldn't give up.
Introduced freeEventNode() which ensures eventNodes don't have a
signalled event in them before returning the node to the freeList.
Callers pass the status from epicsEventWaitWithTimeout() to indicate
whether it was signalled or not. If it timed out we must trigger it
and Wait to clear the event state.
It appears that previously a negative timeout actually implemented a
'wait forever', but the VxWorks and RTEMS implementations both check
for (timeout <= 0) and return immediately if nothing can be done
without waiting.
