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  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
<== Date ==> <== Thread ==>

Subject: "changes" to ChannelProvider::createChannel()
From: Michael Davidsaver <mdavidsaver@gmail.com>
To: EPICS core-talk <core-talk@aps.anl.gov>
Cc: PVData Developers <epics-pvdata-devel@lists.sourceforge.net>
Date: Fri, 18 May 2018 11:16:44 -0700
Unless you, or your site, has written a sub-class of epics::pvAccess::ChannelProvider you
can safely ignore the following.


First a short PSA.  I'm in the process of adding a server API to P4P (PVAccess 4 Python).
This is causing me to investigate the PVA server code with an eye towards clarifying
the semantics of how a ChannelProvider must behave.

For example, I previously mandated that ChannelProvider::createChannel() must be
synchronous[1].  That is, it can only return NULL on error, and must call
ChannelRequester::channelCreated() before returning.

So far the PVA server hasn't actually required this, and has ignored the return of
createChannel() and allowed delayed creation (and search via channelFind()).
However, there is an issue[2] with adjudication when a server has multiple
ChannelProviders, and/or when a process has multiple servers.



To address this I'll probably have to *start enforcing* that channelFind() and createChannel()
be synchronous for server providers as well.



This means that any ChannelProvider which attempts to be asynchronous, or simply forgets
to call channelCreated(), will see the request fail with an error.

I don't think this will break existing code as all the provider implementations which I
checked are already synchronous (PVA client, caProvider, pva2pva, and pvDatabaseCPP).

If there are any implementations I can't see which depend on this behavior, please reply,
or otherwise contact me.

I'll follow up this mail when I have something which can be tested against.


[1] docs for epics::pvAccess::ChannelProvider::createChannel()
http://epics-base.github.io/pvAccessCPP/classepics_1_1pv_access_1_1_channel_provider.html#a52fcce45922422d812ba9f4bcef7612c

[2] https://github.com/epics-base/pvAccessCPP/issues/100

Navigate by Date:
Prev: Jenkins build is back to normal : epics-base-3.14-cyg64 #235 APS Jenkins
Next: Re: Size encoding Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
Navigate by Thread:
Prev: Jenkins build is back to normal : epics-base-3.14-win64s #245 APS Jenkins
Next: Jenkins build is back to normal : epics-base-3.14-win32 #279 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
ANJ, 19 May 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·