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

fixed repeated sentance

Browse Source
This commit is contained in:
Jeff Hill
2006-03-27 15:47:49 +00:00
parent 4ee5d5130e
commit cf231b5af3
1 changed files with 13 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/ca/CAref.html
+13 -16
View File
@@ -1726,8 +1726,8 @@ which vary between OS and even between different versions of the same OS.</p>
<p>If the subscription update producer in the server produces subscription
updates faster than the subscription update consumer in the client consumes
them, then events have to be discarded if the buffering in the server
isn&#x2019;t allowed to grow to an infinite size. This is a law of nature
&#x2013; based on queuing theory of course.</p>
isn&rsquo;t allowed to grow to an infinite size. This is a law of nature
&ndash; based on queuing theory of course.</p>
<p>What is done depends on the version of the CA server. All server versions
place quotas on the maximum number of subscription updates allowed on the
@@ -1749,10 +1749,10 @@ message asking the server to resume with subscription updates. This prevents
slow clients from getting time warped, but also guarantees that intervening
events are discarded until the slow client catches up.</p>
<p>There is currently no message on the IOC&#x2019;s console when a
particular client is slow on the uptake. A message of this type used to exist
many years ago, but it was a source of confusion (and what we will call
message noise) so it was removed. </p>
<p>There is currently no message on the IOC&rsquo;s console when a particular
client is slow on the uptake. A message of this type used to exist many years
ago, but it was a source of confusion (and what we will call message noise)
so it was removed. </p>
<p>There is unfortunately no field in the protocol allowing the server to
indicate that an intervening subscription update was discarded. We should
@@ -2184,16 +2184,13 @@ href="#ca_attach_context">ca_attach_context()</a> using the CA context
identifier that was returned from <a
href="#ca_current_context">ca_current_context()</a> when it is called by the
thread that created the context which needs to be joined. A context which is
to be joined must be created using <a
to be joined must be preemptive - it must be created using <a
href="#ca_context_create">ca_context_create(ca_enable_preemptive_callback)</a>.
It is not possible to attach a thread to a CA context created explicitly
<em>or implicitly</em> with
It is not possible to attach a thread to a non-preemptive CA context created
explicitly <em>or implicitly</em> with
ca_create_context(ca_disable_preemptive_callback). Once a thread has joined
with a CA context it need only make ordinary ca_xxxx() library calls to use
the context. There is no need to specify the context identifier when invoking
the CA y calls because the context identifier is stored in a thread
privatelibrary calls because the context identifier is stored in a thread
private variable by ca_attach_context().</p>
the context. </p>
<p>A CA client library context can be shut down and cleaned up, after
destroying any channels or application specific threads that are attached to
@@ -2249,9 +2246,9 @@ questionable practice for the following reasons.</p>
<ul>
<li>The vxWorks shell thread runs at the very highest priority in the
system and therefore socket calls are made at a priority that is above
the priority of tNetTask &#x2212; a practice that has caused the WRS IP
the priority of tNetTask &minus; a practice that has caused the WRS IP
kernel to get sick in the past. That symptom was observed some time ago,
but we don&#x2019;t know if WRS has fixed the problem.</li>
but we don&rsquo;t know if WRS has fixed the problem.</li>
</ul>
<ul>
<li>The vxWorks shell thread runs at the very highest priority in the
@@ -2266,7 +2263,7 @@ questionable practice for the following reasons.</p>
<ul>
<li>In EPICS R3.13 the CA client library installed vxWorks task exit
handlers behaved strangely if CA functions were called from the vxWorks
shell, ca_task_exit() wasn&#x2019;t called, and the vxWorks shell
shell, ca_task_exit() wasn&rsquo;t called, and the vxWorks shell
restarted. In EPICS R3.14 vxWorks task exit handlers are not installed
and therefore cleanup is solely the responsibility of the user. With
EPICS R3.14 the user must call ca_context_destroy or ca_task_exit to