Experimental Physics and Industrial Control System
|
Alex,
Ø So we can achieve array allocation on demand.
Ø This is just my suggestion :)
While it’s true that there are weaknesses with the current approach
to memory management used by CA (I am working on that), my current thoughts are
that imposing a (max array size) quota on the client isn’t actually a bad idea –
we can protect IOCs running in resource limited situations. Admittedly, it
would be much better if the magnitude of this quota could be client specific – perhaps
supplied by the access control system.
Jeff
Andrew,
Thanks for you
quick response. In my opinoin, if we support variable-sized arrays, there is no
need to specify the EPICS_CA_MAX_ARRAY_BYTES.
So we can achieve array allocation on demand. This is just my suggestion :)
Thanks,
Alex
Hi Alex,
Your subject line is slightly misleading, I don't think you're actually
asking
about support for variable-sized arrays but about the maximum size of an
array that can be transferred over Channel Access.
On Monday 19 January 2009 04:01:46 [email protected] wrote:
>
> Currently, if we dealing with array, its max length is determined at
> "compile-time" as specified by environment variable
> EPICS_CA_MAX_ARRAY_BYTES, this means we can't change the max array
length
> when a CA client is built. If this client connects an IOC supports
larger
> size of arrays, we need to rebuild the client. So do we have any plan
to
> support non-fixed size array?
You are incorrect about this being a compile-time only setting. A
default
value for the maximum length is compiled into the libCom library, but this
can be overridden at runtime by setting the environment variable before you
initialize the CA library — I'm not sure if Win32 supports putenv() but if
not it will have an equivalent that you can use instead. Once CA has
been
initialized though, changing the value will not affect the maximum array
size
that can be transferred.
The maximum size that can be used for a particular client/server
combination
is calculated as the smaller of the two settings on the client and server,
so
an IOC that may not have much memory can limit how much space it has to
allocate for buffering data for clients. Here at the APS we make the
limit
fairly large on our client workstations, and allow the IOCs to control how
big it really gets.
HTH,
- Andrew
--
The best FOSS code is written to be read by other humans -- Harold Welte
|
- References:
- Re: Do we have any plan to support non-fixed size array? Andrew Johnson
- Re: Do we have any plan to support non-fixed size array? Alex . Chen
- Navigate by Date:
- Prev:
Re: Do we have any plan to support non-fixed size array? Alex . Chen
- Next:
Re: wrong timestamps in monitors Ralph Lange
- 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: Do we have any plan to support non-fixed size array? Alex . Chen
- Next:
Re: wrong timestamps in monitors Ralph Lange
- 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, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|