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.
Don't apply the %.tap: %.t and %.xml: %.tap rules to tap and junit
result files from other test frameworks.
(They would overwrite the other frameworks' own rules.)
Use only %.t files in new TESTSCRIPTS.t var for Perl tests.
TAPFILES and JUNITFILES can be appended to by other rules.
The runtests and test-results rules have no direct recipes.
Added run-tap-tests and tap-results rules, simlified recipe.
Make %.tap:%.t and %.xml:%.tap into static pattern rules.
It was created before modern continuous integration systems
came along; Diamond were supposed to run the tests for us,
but they didn't last for very long.
For all standard build ACTIONS, a rule before-<action> is
run just before running that action in the subdirectories
given by the DIRS variable. Only works in Makefiles that
include RULES_DIRS or RULES_TOP.
Lists the directories with failed tests at the end of the build.
It is no longer necessary to use 'make -k' to see the results
of all tests after one or more failures as only the top-level
test-results recipe will generate a build error.
- make runtests a double-colon rule, so that other test frameworks
can add their own recipes independently
- only define runtests:: $TESTSCRIPTS rule when there are TESTSCRIPTS
(to avoid having it run every time when no TESTSCRIPTS are defined)
- $(strip $TAPFILES) inside ifneq to fix trouble when TAPFILES=' '
