Agenda

1. Redesign of the pvData CPP API for arrays (30 mins, *Michael*)

  15 minute talk by Michael outlining his proposals, plus 15 mins

  question time. Outcome should be a plan for how Michael can

  develop his ideas.  Proposal on Tech-talk

2. Review of monitoring support presently in EPICS V4 (20 mins *Marty*)

3. PSI's findings doing EPICS V4 builds (10 mins, *Timo*, *Greg*)

4. NTImage & fourcc (15 mins, *Matej*, *Nikolay*) [4]

Minutes

Present: AJ, GW, MK, MS, RL, TK, MD, GS, DH, NM, BD

Scribe: MS

Chair: GW

PSI's findings doing EPICS V4 builds

GW: PSI created a table showing compilation results of EPICS V4 modules on different platforms. Will be sent to MS. MS is in contact with Dirk to solve VxWorks 5.5 compilation problems.

Redesign of the pvData CPP API for arrays

(lock == lockset)

MD: Michael explains different ordering of separate locks can deadlock (A->B, B->A can deadlock).

Global lock (ordering) solves this problem. It requires to know ahead of time all the locks you want to lock.

Changing locksets is allowed and requires global lock to be acquired.

AJ: What is specific req. for this change?

RL: This will allow atomic access to records that are not in the same lockset. Needed by pvaSrv.

GW: First start prototyping pvaSrv using current lockset code. In addition be the test bed for the new developments Michael is working on.

AJ: This new development will go into 3.15.x.

GW: We need a plan for Michael how to proceed: RL will do pvaSrv on existing lockset code in 3.14. A new version of pvaSrv will use (test) new lockset code.

GW: Would the existing API coexist?

MD: Tried it, but it does not seem to make sense.

AJ: That’s ok, as this API is Core-internal, as far as I can see.

Might create trouble with memory allocation issues on old vxWorks systems.

MD: Will be using free lists.

**********

AI on MD by 15-Mar: Create a prototype of “batched field access” (BFA) API per description in

<uri>

**********

The BFA API can then be used by Ralph for pvaSrv.

MD: Redesign of pvData arrays will continue slowly. He’ll handle discontiguous arrays.

MK: Existing API already allows serving huge arrays not needing to allocate memory for entire array. Marty likes Michael’s idea of having shared pointers to arrays, since it reduces overhead compared to the existing implementation. In addition it also supports discontiguous arrays.

Marty wants “streaming” support.

MD: Disagrees - doesn’t think it’s possible to stream in the way MK describes

- One would have to effectively do a blocking receive call, which would create locking contention.

MK: That’s true.

MD: The same is true of a put lock.

AJ: Is that a slow access or pos. insufficient memory problem?

MD: Yes, either you need 2 copies of the data or you have to block.

MD: Doesn’t dispute usefulness of streaming. But streaming should be handled with a separate API.

MK: What do you propose?

MD: “I propose we punt”

MS:

AJ: One could image doing streaming at a higher level, like an n-type that enclosed only part of the data.

MK: Would like not to give up on the basic idea of shared pointers separately to the discontinuous array API handling.

DH: Can MD remind us where the proposal for the API is?

MD: The proposal is the changes to the pvValueArray class now in code in http://epics-pvdata.hg.sourceforge.net/hgweb/epics-pvdata/pvDataCPP-md/

MK: Asks that MD actually implement his recommendations in the main pvDataCPP.

*********

AI on DH by 11-Mar: Review the pvDataCPP array API proposal of MD, esp w.r.t breaking

the symmetry of the CPP and java implementations of pvData.

*********

If approved MD agrees to implement those API changes (now in pvDataCPP-md) into pvDataCPP.

Review of monitoring support presently in EPICS V4

MK: Merged 3 different documents into one describing pvRequest structure

new document. Proposes others to review the document off-line and we discuss later.

RL: the document describes syntax but not semantic (e.g. deadband).

GW: RL and MK work together on this document.

GW: We need a design (and requirements) on monitoring options.

MK: I’ll take the current document and describe monitoring part more in detail.

The pvRequest document describes a pvRequest structure - how a monitor is requested, it does not define monitoring in general. It describes the developer’s API to that monitoring.

*********

AI on MK by 5-Mar: Further describe monitoring algorithms and add references (URL) in pvRequest document, sufficiently for independent implementation.

*********

NTImage & fourcc

NM: Has a more simple design that will be used in the application he is developing to back-store images. He already had concerns about the complexity of NTImage.

DH: Can we see you design?

NM: I can prepare it until next week.

MS: I need the fourcc code and the image depth & color mode (the image array part of

the NTImage definition).

DH: - will try to answer this question for MS.

************

AI on DH by 5-Mar: Get for MS the fourcc code and other image array param parts necessary for MS’ encoding of the 3-byte encoded BGR (Blue-Green-Red) image. More details of MS’ request is in the email thread.

*************

NM: Can you comment more in the test image server, or talk with DH offline?

DH: Ok.

OUTCOME: DH and NM will review present NTImage design and if NM’s alternative design shows significant promise we’ll review it.

MEETING ENDS.