Experimental Physics and Industrial Control System
|
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.
- 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.
- 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
<2015>
2016
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
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 16 Dec 2015 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|