epics/pcas
0
0
Fork 0
Code Issues Pull Requests Projects Wiki Activity

improved doc on direct acces to fields in the per channel structure

Browse Source
This commit is contained in:
Jeff Hill
2001-10-30 16:57:17 +00:00
parent 7d044bf69c
commit 4e835c2839
1 changed files with 11 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
src/ca/CAref.html
View File

@@ -688,35 +688,31 @@ page 24 for more information on this topic.</p>
<pre><code> printf("The requested ca_XXXX() operation didn't complete successfully because \"%s\"\n",</code></pre>
<pre><code> ca_message ( status ) ); </code></pre>
<pre><code>}
</code></pre>
<p>In the embryonic stages of EPICS it was a common practice to examine a
<p>With the embryonic releases of EPICS it was a common practice to examine a
channel's connection state, its native type, and its native element count by
directly accessing fields in a structure using a pointer stored in type
<code>chid</code>. Likewise, a user private pointer in the per channel
structure was also commonly set by directly accessing fields in the channel
structure. A number of difficulties arise from this practice, which has long
since been deprecated. For example, in release R3.13 it was recognized that
since been deprecated. For example, in release 3.13 it was recognized that
transient changes in certain private fields in the per channel structure
would make it difficult to reliably test the channels connection state using
these private fields directly. Therefore, in release 3.13 of EPICS the names
of certain fields were changed to discourage the practice of directly
accessing them in application code. In R3.14 codes written this way will not
compile. Be advised that if your CA client tool is touching the fields in the
channel structure directly then portability and robustness will be
compromised. The probability of EPICS minor release upgrade recompilation
dependency will also increase. Codes intending to maintain the highest degree
of portability over a wide range of EPICS versions should be especially
careful. For example such codes should replace all instances of
<code>channel_id-&gt;type</code> with
these private fields directly. Therefore, in release 3.13 the names of
certain fields were changed to discourage this practice. Starting with
release 3.14 codes written this way will not compile. Codes intending to
maintain the highest degree of portability over a wide range of EPICS
versions should be especially careful. For example you should replace all
instances off <code>channel_id-&gt;count</code> with
<code>ca_element_count(channel_id)</code>. This approach should be reliable
on all versions of EPICS in use today. The construct <code>ca_puser(chid) =
xxxx</code> is particularly problematic. The best mechanisms for setting the
per channel private pointer will be to pass the user priate pointer in when
per channel private pointer will be to pass the user private pointer in when
creating the channel. This approach is implemented on all versions.
Otherwise, you can also use <code>ca_set_puser(CHID,PUSER)</code>, but this
will work only on post beta releases of R3.13 and on R3.14. </p>
function is available only after the first official (post beta) release of
EPICS 3.13.</p>
<h2><a name="Function Call Reference"></a>Function Call Reference</h2>