On Tuesday 10 May 2011 19:29:17 Andrew C. Starritt wrote:
> As part of the "ca.py - Throws error - workaround" thread there was some
> discussion whether a CA client should call ca_clear_subscription when it
> detects that a server has disconnected and presumably re-subscribe when
> the server re-connects.
> Although the CA library automatically maintains the subscription, wouldn't
> it be better that when the PV re-connects, the client should do a ca_get
> (or ca_get_array or ca_get_array_callback) and a new
It's going to be quicker if you don't do that; the client library has already
stored all of the information it needs to reconnect your subscription, and if
you tear it down and rebuild it every time it will have to free and then
reallocate memory for that internal storage. Not a biggie, but it all takes
resources and a little bit of CPU time.
> I would do this because the nature of a PV might have changed and a new
> ca_get would ensure that the client has the latest associated data
> (e.g. precision, EGU, enumeration values), and a new subscription because
> the field type and/or number of elements may have changed as well.
In R3.14.11 we introduced a new DBE_PROPERTY event subscription type. The
intention is that a client will use this to subscribe to a channel for which
it wants to know metadata such as EGU, precision, ENUM strings etc. The IOC
currently only generates DBE_PROPERTY events at runtime for the mbbo and mbbi
records when there is a change to the ENUM strings, but eventually this will
expand. This subscription replaces that single ca_get() of the extended DBR
type that we currently do on connection, because the client will always be
sent one monitor event of this type after a connection is (re)made. This
should simplify the client code slightly.
Of course it doesn't really help if the data type of the PV changes and you
really want to subscribe using the channels native type, but that will require
you to do more work in the client anyway and in practice is pretty rare
(sufficiently so that I think there is still be a bug in the IOC's dbCa link
handling if a link target changes type). Unless you are transferring large
arrays I would just recommend subscribing using the data type that you want
the result in and let the library take care of the data conversions.
An error is only a mistake if you don't learn from it.
When you learn something from it, it becomes a lesson.
- Disconnected PVs Andrew C. Starritt
- Navigate by Date:
RE: asynPortDriver callbacks to I/O Intr, how to propagate an error? Mark Rivers
Area Detector Szalata, Zenon M.
- Navigate by Thread:
Re: Disconnected PVs Matt Newville
asynPortDriver callbacks to I/O Intr, how to propagate an error? Angus Gratton