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: Fundamental Types document |
From: | Andrew Johnson <[email protected]> |
To: | Jeff Hill <[email protected]> |
Cc: | "'EPICS core-talk'" <[email protected]> |
Date: | Wed, 15 Jun 2005 11:15:43 -0500 |
Jeff Hill wrote:
I revised my comments on the wiki as follows.
I think email (via core talk) is probably a far simpler medium to use for discussions, as we can always use the core-talk archive to review past dicussions. The Wiki's talk pages don't work terribly well in practice for live conversations (they're not event driven), as you've obviously realized since you're emailing your comments as well as posting them.
2) You have created interface classes for buffers, arrays, enumerated, strings etc. All of these interfaces are already in data access. Was there a good justification to create new ones? In any case, it seems that we should have the goal of using the same interfaces for each of the fundamental data types?
Agreed about the goal, but your interfaces don't necessarily take into account all of our requirements, and we think some of your interfaces are stricter than they need to be, which harms performance. I suspect we would have few problems implementing most of your interfaces on top of ours, but adopting ours should be more efficient since you don't have to do everything one character or element at a time - we expose a whole segment at once.
3) These interfaces seem to require contiguous storage of random sized blocks of characters. Doesn't this preclude use of fixed length buffer based (free list based) memory allocation, and therefore almost guarantee fragmentation of memory. Note that fragmentation isnt just a binary condition (memory of a particular size is or isnt available). Fragmentation is also an efficency isssue because most random sized block memory allocators require searching for the best sized free block. Note that one of my goals for V4 is to no longer require EPICS_CA_MAX_ARRAY_BYTES.
Go back and read the section on the EpicsBuffer interface again; none of our classes require contiguous buffer storage. Any segmented implementation has to provide segments that are (presented as) an exact multiple of the basic element size as given by the parameter to EpicsBufferCreator::create(), but the EpicsBuffer interface and the classes that use it were explicitly designed to allow both contiguous and segmented buffer implementations to be used interchangably without having to know which you are using.
Since we never really write down and agree what all the detailed requirements are, but just present each other with code snippets that implement our view of them, I think we're going to continue to have disagreements like these. It would speed things up immensely if we could first agree in writing on what we are going to accomplish *before* we actually start implementing it (and I plead as guilty as everyone else on that charge).
- Andrew -- Podiabombastic: The tendency to shoot oneself in the foot.