Experimental Physics and Industrial Control System
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. 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 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.
 docs for epics::pvAccess::ChannelProvider::createChannel()
- Navigate by Date:
Jenkins build is back to normal : epics-base-3.14-cyg64 #235 APS Jenkins
Re: Size encoding Michael Davidsaver
- Navigate by Thread:
Jenkins build is back to normal : epics-base-3.14-win64s #245 APS Jenkins
Jenkins build is back to normal : epics-base-3.14-win32 #279 APS Jenkins