EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <2020>  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <2020>  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: RTEMS/osdMessageQueue.c
From: "Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov>
To: Michael Davidsaver <mdavidsaver at gmail.com>
Cc: EPICS core-talk <core-talk at aps.anl.gov>
Date: Tue, 26 May 2020 03:45:11 +0000
On May 25, 2020, at 1:37 PM, Michael Davidsaver <mdavidsaver at gmail.com> wrote:

It looks like the switch to ci-scripts for Base added TEST=NO for the RTEMS builds.
This needs to be removed.

On 5/25/20 10:49 AM, Johnson, Andrew N. via Core-talk wrote:
tl;dr:  I propose that we delete the RTEMS implementation of osdMessageQueue before making the 7.0.3.2 release, it has bugs which the default implementation doesn’t show.

I don't have a strong objection to this.  Although, I'm not enthused to be
making this change days before a release, when it will go out the door with
very little testing.  Whatever is going on, I suspect that it isn't a
regression (the bugs in the default impl weren't).

How about marking your new test as a skip until after the release?

Earlier tonight I pushed commits removing “TEST=NO” from the RTEMS builds and implementing the test skips as you suggested, although I would prefer that we have a fix in place for the release. Reducing the amount of code in Base would seem a better solution to me than keeping a known-buggy implementation.

However unfortunately the RTEMS builds didn’t run ‘make test-results’ after generating the tapfiles, so although the builds have finished I have no idea what the results were.


The long version:

While merging 3.15 into 7.0 last night I ran the tests on RTEMS (qemu) and discovered that the implementation of the epicsMessageQueue fails the additional tests that I wrote for this API. I was expecting the Travis-CI builds to fail but

I forgot that they don’t actually run the tests at all.

I guess there is something to be said for developing on the development branch.

As an FYI, that merge up from 3.15 was made many times harder than the one before it by the api-headers change. Git didn't recognize any of the C/C++ source changes from the 3.15 branch as applying to files on the 7.0 branch that had earlier been moved into the modules/ structure, so I had to do the merges by hand. I don’t intend to do that again, so unless someone else agrees to pick up the back-porting work I think Base-3.15.8 may have been our last 3.15 release.


As I look at epicsMessageQueueTest.cpp I don't see any test which
deliberately times out.

The new SleepySender and SleepyReceiver tests do actually do that, just not obviously. I suspect there may be one or two other APIs in libCom with timeouts which don’t have tests for the timeout operations – a Virtual Codeathon job maybe…


Heinz, If there is a measurable performance advantage in providing an implementation of the epicsMessageQueue based on Posix message queues I don’t have an objection in our providing one for other OSs, but we would have to work out how to exclude Darwin builds from the Posix rule since MacOS X doesn’t have a mqueue.h header at all.

I do remember that there are a few places in the default implementation where in the course of a single send or receive operation there may be multiple task switches that could occur between the sending and receiving threads. However if there isn’t likely to be much of a performance gain I don’t know whether it’s worth spending much time on this.

- Andrew

-- 
Complexity comes for free, simplicity you have to work for.

Replies:
Re: RTEMS/osdMessageQueue.c Michael Davidsaver via Core-talk
Re: RTEMS/osdMessageQueue.c Heinz Junkes via Core-talk
References:
RTEMS/osdMessageQueue.c Johnson, Andrew N. via Core-talk
Re: RTEMS/osdMessageQueue.c Michael Davidsaver via Core-talk
Navigate by Date:
Prev: Jenkins build became unstable: epics-7.0 » linux32 #225 APS Jenkins via Core-talk
Next: Re: RTEMS/osdMessageQueue.c Michael Davidsaver via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <2020>  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: RTEMS/osdMessageQueue.c Gedare Bloom via Core-talk
Next: Re: RTEMS/osdMessageQueue.c Michael Davidsaver via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <2020>  2021  2022  2023  2024 
ANJ, 02 Jun 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·