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: pvData introduction |
From: | "Johnson, Andrew N. via Core-talk" <[email protected]> |
To: | "[email protected]" <[email protected]> |
Date: | Fri, 27 Sep 2019 15:50:14 +0000 |
Hello Kay, On 9/27/19 7:33 AM, Kasemir, Kay via Core-talk wrote:
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.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]. 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. |