Experimental Physics and Industrial Control System
|
Hello Kay,
On 9/27/19 7:33 AM, Kasemir, Kay via Core-talk wrote:
Only shortcoming would be that 'info' operations hands you an empty container.
So instead of for example
StructureDescriptor "timeStamp": { LongDescriptor "secondsPastEpoch", IntDescriptor "nanoseconds", ... }
you get a
PVAStructure "timeStamp": { PVALong "secondsPastEpoch" = 0, PVAInt "nanoseconds" = 0, ... }
The caller of PVAChannel.info() needs to know that the obtained PVAStructure is empty, it's only meant to describe the data.
Nothing keeps you from printing the timestamp with secondsPastEpoch, nanoseconds, .. and then you see that all values are 0, NaN, [].
Yes, that means inside the client you now have a PVALong with 8 wasted bytes for the long value = 0, a PVAInt with 4 wasted bytes for the int value = 0.
But in the bigger picture, those long, int, double values don't waste much space.
Would be bad if fetching the info for an NTNDArray got the actual int[2,000,000] data array, but all you get is int[0].
At one point we had array types that had a fixed maximum array length. Do those types still exist and can you find out what the maximum length of an array is? The idea being that an embedded client or server with limited RAM would be able to allocate storage
for the array at connection time based on that max length, and would never have to free a too-small buffer and allocate a larger one.
The IOC already has that kind of limitation; you can't resize a waveform record at runtime and it would be better for clients to find out
before the data starts going over the network that they can't put 2GB of data into a 3 element waveform. I don't know if/how the PVA protocol handles that, but a CA server tells its clients what the maximum array size of a channel is at connection time.
The ability to communicate these kinds of limits is the one thing about your Java rewrite that concerns me, I hope it's not an issue (especially when a Java client is talking to a C++ server). I might have more concerns about API compatibility for a similar
pvDataCPP rewrite though, given that the community has probably written a lot more C++ code calls the PVA modules than it has Java code.
BTW, have you talked to Greg White about the new Java API at all? He might have comments...
- Andrew
--
Complexity comes for free, Simplicity you have to work for.
|
- Replies:
- Re: pvData introduction Kasemir, Kay via Core-talk
- Re: pvData introduction Michael Davidsaver via Core-talk
- References:
- pvData introduction Timo Korhonen via Core-talk
- Re: pvData introduction Kasemir, Kay via Core-talk
- Re: pvData introduction Timo Korhonen via Core-talk
- Re: pvData introduction Kasemir, Kay via Core-talk
- Navigate by Date:
- Prev:
Re: pvData introduction Kasemir, Kay via Core-talk
- Next:
Build failed: epics-base base-7.0-318 AppVeyor via Core-talk
- 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: pvData introduction Kasemir, Kay via Core-talk
- Next:
Re: pvData introduction Kasemir, Kay via Core-talk
- 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, 27 Sep 2019 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|