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:
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.
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 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.
|