From 7e0b996c72a025eda58345b05fa3207bdc076117 Mon Sep 17 00:00:00 2001 From: Jeff Hill Date: Mon, 22 Mar 2004 23:22:22 +0000 Subject: [PATCH] added sections on behavior changes in R3.14.5 --- src/ca/CAref.html | 119 ++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 98 insertions(+), 21 deletions(-) diff --git a/src/ca/CAref.html b/src/ca/CAref.html index 240a7a0ff..04c56788f 100644 --- a/src/ca/CAref.html +++ b/src/ca/CAref.html @@ -40,6 +40,7 @@ border="0" src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" height="31" width="88">

Modified on $Date$

+

Table of Contents

@@ -101,6 +102,8 @@ style="color: #FF5F00">(under development)
  • A server's IP address was changed
    • +
  • Put Requests Just Prior to Process Termination + Appear to be Ignored
  • ENOBUFS Messages
    • @@ -123,6 +126,8 @@ style="color: #FF5F00">(under development) Applications
  • Avoid Emulating Bad Practices that May Still be Common
    • +
  • Calling CA Functions from the vxWorks Shell + Thread

    • Functionality Index 

    @@ -153,8 +158,9 @@ style="color: #FF5F00">(under development)
  • ca_clear_channel
  • ca_clear_subscription
  • ca_client_status
    • -
  • ca_context_status
    • +
  • ca_context_create
  • ca_context_destroy
    • +
  • ca_context_status
  • ca_create_channel
  • ca_create_subscription
  • ca_current_context
    • @@ -496,14 +502,29 @@ subnets. See "routeLib" in the vxWorks reference manual.

    If the CA client library does not see a beacon from a server that it is connected to for EPICS_CA_CONN_TMO seconds then an state-of-health message is sent to the server over TCP/IP. If this state-of-health message isn't -promptly replied to then the client will assume that the server is no longer -present on the network and disconnect. Disconnecting implies notification of -client side application programs via function callbacks. The parameter +promptly replied to then the client library will conclude that channels +communicating with the server are no longer responsive and inform the CA +client side application via function callbacks. The parameter EPICS_CA_CONN_TMO is specified in floating point seconds. The default is typically 30 seconds. For efficient operation it is recommended that EPICS_CA_CONN_TMO be set to no less than twice the value specified for EPICS_CA_BEACON_PERIOD.

    +

    Prior to EPICS R3.14.5 an unresponsive server implied an immediate TCP +circuit disconnect, immediate resumption of UDP based search requests, and +immediate attempts to reconnect. There was concern about excessive levels of +additional activity when servers are operated close to the edge of resource +limitations. Therefore with version R3.14.5 and greater the CA client library +continues to inform client side applications when channels are unresponsive, +but does not immediately disconnect the TCP circuit. Instead the CA client +library postpones circuit shutdown until receiving indication of circuit +disconnect from the IP kernel. This can occur either because a server is +restarted or because the IP kernel's internal TCP circuit inactivity keep +alive timer has expired after a typically long duration (as is appropriate +for IP based systems that need to avoid thrashing during periods of excessive +load). The net result is less search and TCP circuit setup and shutdown +activity suring periods of excessive load.

    +

    Dynamic Changes in the CA Client Library Search Interval

    @@ -1314,6 +1335,15 @@ if ( status != ECA_NORMAL ) {

    Channel Access Data Types

    +

    CA channels form a virtual circuit between a process variable (PV) and a +client side application program. It is possible to connect a wide variety of +data sources into EPICS using the CA server library. When a CA channel +communicates with an EPICS Input Output Controller (IOC) then a field is a +specialization of a PV, and an EPICS record is a plug compatible function +block that contains fields, and the meta data below frequently are mapped +onto specific fields within the EPICS records by the EPICS record support +(see the EPICS Application Developer Guide).

    +

    Arguments of type chtype specifying the data type you wish to transfer. They expect one of the set of DBR_XXXX data type codes defined in db_access.h. There are data types for all of the C primitive types, and there @@ -1595,7 +1625,9 @@ Otherwise, the user's call back functions will be called only when the main initiating channel access thread is executing inside of the CA client library. When the CA client library invokes a user's call back function it will always wait for the current callback to complete prior to executing -another call back function.

    +another call back function. Programmers enabling preemptive callback should +be familiar with using mutex locks to create a reliable multi-threaded +program.

    To set up a traditional single threaded client you will need code like this (see ca_context_create and ) .

    "application pdq calling ca_context_create" );

    To set up a preemptive callback enabled CA client context you will need -code like this (see ca_context_createand ca_context_create and CA Client Contexts and Application Specific Auxiliary -Threads) .

    +Threads).

    SEVCHK ( ca_context_create(ca_enable_preemptive_callback ), "application pdq calling ca_context_create" );

    @@ -1616,26 +1648,39 @@ Threads) .

    CA Client Contexts and Application Specific Auxiliary Threads

    -

    It may be necessary for several CA client side tools running in the same +

    It is often necessary for several CA client side tools running in the same address space (process) to be independent of each other. For example, the database CA links and the sequencer are designed to not use the same CA client library threads, network circuits, and data structures. Each thread that calls ca_context_create() for the first -time either directly, or implicitly when calling a CA routine for the first -time, creates a CA client library context. A CA client library context -contains all of the threads, network circuits, and data structures required -to connect and communicate with the channels that a CA client application has -created. The priority of auxiliary threads spawned by the CA client library -are at fixed offsets from the priority of the thread that called ca_context_create(). An application specific -auxiliary thread can join a CA context by calling ca_context_create(). An application +specific auxiliary thread can join a CA context by calling ca_attach_context() using the CA context identifier that was returned from ca_current_context() when it was called by the -thread that called ca_context_create(). A CA -client library context can be shut down and cleaned up, after destroying any -channels or application specific threads that are attached to it, by calling -ca_context_destroy().

    +href="#ca_current_context">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 +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().

    + +

    A CA client library context can be shut down and cleaned up, after +destroying any channels or application specific threads that are attached to +it, by calling ca_context_destroy(). The +context may be created and destroyed by different threads as long as they are +both part of the same context.

    Polling the CA Client Library From Single Threaded Applications

    @@ -1677,6 +1722,38 @@ Otherwise, you can also use ca_set_puser(CHID,PUSER), but this function is available only after the first official (post beta) release of EPICS 3.13.

    +

    Calling CA Functions from the vxWorks Shell +Thread

    + +

    Calling CA functions from the vxWorks shell thread is a somewhat +questionable practice for the following reasons.

    + + + + +

    Function Call Reference

    ca_context_create()