EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: pending PVA changes
From: Michael Davidsaver <[email protected]>
To: EPICS core-talk <[email protected]>, PVData Developers <[email protected]>
Date: Mon, 25 Jun 2018 11:25:08 -0700
There are a couple of changes which will likely be landing shortly in pvDataCPP and pvAccessCPP.

1. #include cleanup.

I'm frequently rebuilding pvAccessCPP these days.  In an attempt to reduce
compilation time I'm thinking to replace some #include with forward declarations,
and maybe to split some headers up.

This will undoubtedly break some dependent modules.  I'll keep an eye on the CI
builds and add/suggest additional #includes as necessary.


2. Field de-duplication

Type comparison has been fairly expensive, and consequently isn't checked as
often as I would like.  This has led to several crashes related to type changes.

In an effort to remove this category of error, I've been testing a change which
maintains a global hash table of all Field instances.  This ensures that identical
definitions will share the same Field instance(s), and thus Field equality implies
pointer equality, and vis. versa.  So type comparison becomes very quick.  There is
naturally a performance hit to maintaining this table.  I've measured this in one
case as an increase in FieldBuilder::createStructure() runtime of 1.5 us -> 6 us.

I'm inclined to accept this hit as imo. good code shouldn't be creating new types very often.

Note that this only effects FieldBuilder::createStructure() and friends.  It has
no effect on PVDataCreate::createPVStructure() et al.


3. New PVA server API

This is my attempt at a simplified PVA server API to complement my previous attempt
at a simplified client API (see pva/client.h).  This underpins the newly created
server API bindings of P4P.

An example

http://mdavidsaver.github.io/pvAccessCPP/examples_mailbox.html

API documentation (still a work in progress)

http://mdavidsaver.github.io/pvAccessCPP/group__pvas.html#details

As comparisons will undoubtedly be made with Marty's pvDatabaseCPP
let me try to summarize some of the differences.

1. Not a singleton.

2. PVs not Records

  No user visible lock, nor concept of "process".
  Hooks provided to react to Put and RPC requests, which may be concurrent.

3. server side connection handling.

  Supports type change, and the notion of not having a type (while type change in progress).
  Provides hooks to react when the client list becomes (not) empty.
  Allows server to force client disconnect.

Replies:
Re: pending PVA changes (one more) Michael Davidsaver

Navigate by Date:
Prev: Build failed in Jenkins: epics-7.0-windows » STATIC,win64 #48 APS Jenkins
Next: Re: pending PVA changes (one more) Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Jenkins build is back to normal : epics-7.0-windows » STATIC,win64 #49 APS Jenkins
Next: Re: pending PVA changes (one more) Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 27 Jun 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·