RE: Arrays and portable channel access server

[johill@lanl.gov (Jeff Hill)]

Hi Tony,

I am working on a patch for this issue. It appears that this is caused by
problems when transferring from one GDD to another. There appears to be
code missing in GDD which should examine the bounds on the destination GDD
and properly extract the specified sub-matrix from the source GDD.

Note that the CA client API library can currently only specify 0-N elements.
Nevertheless, it is normal to return less than the N elements specified
in the ca_add_event() request if there are less than N elements available.
The count argument passed to the event call back specifies the actual number
of elements that are returned.

I was working on a fix for this earlier this month when other LEDA project
related tasks were elevated to a higher priority. I intend to resume my
efforts on this when I return from ICALEPCS. Sorry that I didn't respond
earlier. I seem to be in a chronic state where I start one task and then
get interrupted on to another one these last few months.

Jeff


> -----Original Message-----
> From: Tony Cox - (415)926-3105 [mailto:TCOX@SSRL.SLAC.STANFORD.EDU]
> Sent: Wednesday, September 01, 1999 4:40 PM
> To: TECH-TALK@aps.anl.gov
> Subject: Arrays and portable channel access server
>
>
> Hello folks,
>
> 	I'm coding up a PCAS here at SSRL & I'm having trouble
> returning a variable length array.
>
> 	The array, maximum size 2000, is all floats. Whenever it changes,
> I get called at my monitor routine, but sometimes not all 2000 elements
> are available. I just want to return the data which is valid to waiting
> clients.
>
> 	So (just once, during initialization) I set up an appropriate
> 	gddAtomic...
>
> 		gddAtomic( gddAppType_value, aitEnumFloat32, 1, 2000);
>
>  	...permanently allocate myself a data area...
>
> 		aitFloat32* data = new aitFloat32[ 2000];
>
> 	...and do the normal referencing
>
> 		gdd->putRef( data, ...);
> 		gdd->reference();
>
>
> 	Now when the data comes in, I stuff as much of the data area
> as I can with valid data, try to change characteristics on the gdd,
> and then use 'postEvent' to inform the clients.
>
> 	It is the 'try to change characteristics...' bit which has
> me stumped.
> My first quess was to change the bounds on the gdd to reflect the new
> length. No joy. The second was to reset the gdd but that didn't seem to
> produce results either. The nice Lansce documentation is silent
> on how to do
> this, and the example server doesn't do it.
>
> 	Regardless of what I try, my clients get either as much data as they
> have requested (all are using ca_add_array_event), or the whole
> 2000 elements
> (if the 2nd parameter to ca_add_array_event is 0). I note, however, that
> my PV::maxBounds routine is being called at some point in the dispatching;
> presumably, *this* is where it is getting the size to return.
> (Unfortunately,
> maxBounds isn't being called from postEvent, or I'd dummy up the
> maxBounds in
> an attempt to get the behaviour I want).
>
>
> 	So whats the buzz? Am I asking more of the pCAS than it's capable of
> delivering, or am I misunderstanding what is going on here??
>
>
> 	Tony Cox
> 	Cox Realtime Corp.
> 	Los Gatos, CA
> 	tc@coxrt.com
>