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
<2018>
2019
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
<2018>
2019
2020
2021
2022
2023
2024
|