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