EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Small arrays in rsrv
From: Ralph Lange <[email protected]>
To: EPICS Core-Talk <[email protected]>
Date: Tue, 28 Apr 2015 10:48:45 +0200
Update:

I spent the major part of two afternoons on this and decided to drop it.

While I was able to do the code changes on the part that pushes updates on the queue (in dbScan.c) with reasonable effort, the counterpart (the event_task pulling data from the queue) eventually calls dbGet() (in dbAccess.c) to get the data out.
That code is bad and fragile enough already, it is being called from different contexts, and I did not manage to add yet another layer of conditional execution without breaking or segfaulting or pulling zeros from the wrong place.

I would say this is in a state where adding another option would call for a 100% unit test followed by a refactoring and redesign.
Probably worth doing, but not a minor thing that goes between 3.15.1 and 3.15.2. Codeathon work?

As for my original use case, I found that rsrv is actually dropping updates in more than one place.
  1. When pushing in the queue: a. If there is an update already on the queue for the same subscription, of the record-reference type, the new update is dropped. b. If the connection is in "flow control mode" or the queue is full, the last update in the queue is overwritten.
  2. When pulling from the queue: if the connection is in "flow control mode", all updates are pulled and dropped except for the last one.
Allowing small arrays to be queued as-value would prevent dropping events under the first condition (1a.), but not in the other cases.

Cheers,
~Ralph


On 03/04/2015 21:27, Andrew Johnson wrote:
On 04/03/2015 11:12 AM, Michael Davidsaver wrote:
To be honest I'm slightly surprised that we haven't already done that.
I'd be in favour of the change Ralph is suggesting using the size, and I
would even suggest considering allowing the user to adjust how large the
log buffer is at initialization time. This would allow users to turn on
DB_EVENT_LOG_STRINGS (which nobody else really knows about anyway)
without recompiling.
Selecting the size at runtime might mean a more invasive change to
db_field_log.
True, but I'm encouraging Ralph to look at that further possibility as
well; we don't know for sure how much more complex it might be until
someone actually codes it (it might be as simple as adding an integer
variable and 2 additions).

A 3.15 change IMHO, as is Matej's pCAS update.
To me, depends on final complexity.
Agreed, I'm just suggesting that development be done on the 3.15 branch
as it's easier to merge a feature branch into a later release branch
than it is into an earlier one.

- Andrew


References:
Small arrays in rsrv Ralph Lange
Re: Small arrays in rsrv Michael Davidsaver
Re: Small arrays in rsrv Andrew Johnson
Re: Small arrays in rsrv Michael Davidsaver
Re: Small arrays in rsrv Andrew Johnson

Navigate by Date:
Prev: Re: EPICS Base R3.15.2-pre1 available Ralph Lange
Next: Jenkins build is still unstable: epics-base-3.15-win64s #155 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Small arrays in rsrv Andrew Johnson
Next: Re: Small arrays in rsrv Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·