From cf231b5af365770d18fcf0ac9400f2a277644dd1 Mon Sep 17 00:00:00 2001 From: Jeff Hill Date: Mon, 27 Mar 2006 15:47:49 +0000 Subject: [PATCH] fixed repeated sentance --- src/ca/CAref.html | 29 +++++++++++++---------------- 1 file changed, 13 insertions(+), 16 deletions(-) diff --git a/src/ca/CAref.html b/src/ca/CAref.html index 64d124c80..0a63fc57b 100644 --- a/src/ca/CAref.html +++ b/src/ca/CAref.html @@ -1726,8 +1726,8 @@ which vary between OS and even between different versions of the same OS.

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’t allowed to grow to an infinite size. This is a law of nature -– based on queuing theory of course.

+isn’t allowed to grow to an infinite size. This is a law of nature +– based on queuing theory of course.

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.

-

There is currently no message on the IOC’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.

+

There is currently no message on the IOC’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.

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() using the CA context identifier that was returned from ca_current_context() 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 ca_context_create(ca_enable_preemptive_callback). -It is not possible to attach a thread to a CA context created explicitly -or implicitly with +It is not possible to attach a thread to a non-preemptive CA context created +explicitly or implicitly 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().

+the context.

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.