> While you're responding on this subject could you definitively answer
> Micheal's original questions, which were:
> > Firstly, is it possible for the element count of a channel to change
while
> > the channel is connected? I'm thinking in particular of the case when
> > using camonitor (well, ok, I mean ca_create_subscription()) to monitor a
> > waveform PV. Each event_handler callback is informed of the dbr count -
> > but as far as I can tell, it's always the maximum waveform size, even if
> > NORD is smaller.
Current behavior:
1) If the subscription request specifies a nonzero element count, then CA
always returns exactly the number of elements that the client application
requested, and zero pads if there are currently less elements available than
requested. The subscription request is rejected by the client library, if
the channel is currently connected, and the subscription request specifies
an element count greater than the element count received from the server
when the channel connects.
2) If the subscription request occurs before the channel connects and it
specifies an element count of zero, then CA always returns exactly the
element count that the client library received from the server when the
channel connects, and zero pads if there are currently less elements
available than requested.
> > Is the fact that the update size doesn't change,
> > ca_element_count() always
> > reports the NELM, and subscribing with zero count gets the full
wavelength,
> > is this restriction fundamental to channel access, a limitation of the
> > channel access server, or just something that hasn't been implemented in
> > the waveform record? This question becomes more interesting as we use
> > waveform records for large images!
The current behavior is partly resulting from a desire for a clear, concise,
safe, and consistent api design. There was a desire for the core behavior of
ca_get, ca_get_callback, and ca_create_subscription to all be consistent. It
would be unsafe, for example, for the number of elements returned by ca_get
to not match the number of elements requested by the client application, and
the other two were implemented consistent with ca_get. Once we ended up with
that behavior then it's not easy to change now because of a desire to remain
backwards compatible.
If the database interfaces provided an efficient mechanism for querying the
element count then it would be safe to conclude that the restrictions
presented at CA interfaces are imposed solely by code within CA.
Near-term:
Nevertheless, if one is slightly cavalier about backwards compatibility then
we could change the behavior when subscribing, or calling ca_get_callback,
and specifying zero elements to mean "return the current number of
elements". The behavior would also be modified to not change if the
subscription request is made before, or after, when the channel connects (as
it does now). That would probably be a safe conservative option which
provides important new functionality, and probably breaks very few if any
legacy clients.
Long Term:
I am proposing that client applications specify some complete set, or
subset, of the hypercube slice that they desire. If a bound (a single
dimension's bound) on the slice is left unspecified, then they would receive
the entire extent of the array (currently occupied) for that bound.
I will reflect questions about the exact behavior of the local database
links back to Andrew :-)
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA
> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Monday, October 05, 2009 10:20 AM
> To: Jeff Hill; [email protected]
> Cc: [email protected]
> Subject: Re: Channel access dynamic array subscription update element
> count
>
> Jeff,
>
> While you're responding on this subject could you definitively answer
> Micheal's original questions, which were:
>
> > Firstly, is it possible for the element count of a channel to change
> while
> > the channel is connected? I'm thinking in particular of the case when
> > using camonitor (well, ok, I mean ca_create_subscription()) to monitor a
> > waveform PV. Each event_handler callback is informed of the dbr count -
> -
> > but as far as I can tell, it's always the maximum waveform size, even if
> > NORD is smaller.
>
> > Is the fact that the update size doesn't change, ca_element_count()
> always
> > reports the NELM, and subscribing with zero count gets the full
> wavelength,
> > is this restriction fundamental to channel access, a limitation of the
> > channel access server, or just something that hasn't been implemented in
> > the waveform record? This question becomes more interesting as we use
> > waveform records for large images!
>
> Thanks,
>
> - Andrew
> --
> The best FOSS code is written to be read by other humans -- Harald Welte
- References:
- Channel access and ca_element_count michael.abbott
- RE: Channel access and ca_element_count Jeff Hill
- RE: Channel access dynamic array subscription update element count Jeff Hill
- Re: Channel access dynamic array subscription update element count Andrew Johnson
- Navigate by Date:
- Prev:
Re: Channel access and ca_element_count Benjamin Franksen
- Next:
RE: Channel access dynamic array subscription update element count Jeff Hill
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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: Channel access dynamic array subscription update element count Jeff Hill
- Next:
javaIOC Marty Kraimer
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|