Re: What's calling get_array_info?

[Michael Davidsaver <mdavidsaver@bnl.gov>]

Hi Tim,

On 1/9/2013 12:48 PM, Tim Mooney wrote:

Overwriting pfield does cause problems.  When you post the array, you have to post all three pfield addresses, because you can't know which was in use at the time a client connected.  (As you know, clients actually connect to array addresses, not to fields.) There are three pfield addresses, because buffers are not allocated until a detector field is first used, so the first address is the null array, and the other two are the actual data buffers.  The posting only alerts clients that new data is available; the real buffer address isn't specified until the client calls get_array_info().  It's awkward and unsatisfying, but it works.

Tim

Ok, so there are issues, but not as bad as they could be.

One of the things I am considering is to modify the code which calls get_array_info() to be aware that paddr->pfield might be modified, and clean up afterward.  Would this adversely effect sscanRecord?

DBADDR *paddr;
{
  void *temp = paddr->pfield;
  ...->get_array_info(paddr, ...);
  dbGet(paddr, ...);
  paddr->pfield = temp;
}

I had also considered adding another argument to get_array_info(), or another member to DBADDR.  However, as there is already code modifying DBADDR, that seems like the way to go.


Michael

---

From: "Michael Davidsaver" <mdavidsaver@bnl.gov>
To: "Ned Arnold" <nda@aps.anl.gov>
Cc: tech-talk@aps.anl.gov
Sent: Wednesday, January 9, 2013 11:02:49 AM
Subject: Re: What's calling get_array_info?

On 1/9/2013 11:57 AM, Ned Arnold wrote:

The sscan record in synapps does that ... if you are looking for an example.  It "double buffers" the collected data allowing a client more time to access it.

From sscanRecord.c:

if (precPvt->validBuf == B_BUFFER) {
      paddr->pfield = precPvt->detBufPtr[group].pBufB;
} else {
      paddr->pfield = precPvt->detBufPtr[group].pBufA;
}

Well how about that.  This is just what I was thinking.  I had assumed that simply overwriting pfield would cause problems.  I'll definitely take a close look at this code.

Thanks,
Michael



--

Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab