The EPICS_CAS_BEACON_PERIOD parameter determines the server's beacon period and is specified in floating point seconds. The default is typically 15 -seconds. See also EPICS_CA_CONN_TMO and Dynamic Changes in the CA Client Library Search +seconds. See also EPICS_CA_CONN_TMO and +Dynamic Changes in the CA Client Library Search Interval.
CA servers build a list of addresses to send beacons to during @@ -1598,7 +1598,7 @@ command line is used.
stdout.The -s option allows to specify an interest level for calling Channel
-Access' internal report function ca_client_status(), that prints lots of
+Access' internal report function ca_client_status(), that prints lots of
internal informations on stdout, including environment settings, used CA ports
etc.
ca_pend_event()
+ or ca_poll()
to process their CA input queue, then a significant mbuf consuming backlog
can occur in the server.
@@ -2052,11 +2053,12 @@ example, be beneficial when tuning an archiver installation.
Significant performance gains can be realized when the CA client library
doesn't wait for a response to return from the server after each request. All
requests which require interaction with a CA server are accumulated (buffered)
-and not forwarded to the IOC until one of ca_flush_io, ca_pend_io,
-ca_pend_event, or ca_sg_pend are called allowing several operations to be
+and not forwarded to the IOC until one of ca_flush_io(),
+ca_pend_io(), ca_pend_event(), or
+ca_sg_block() are called allowing several operations to be
efficiently sent over the network together. Any process variable values written
-into your program's variables by ca_get() should not be referenced by your
-program until ECA_NORMAL has been received from ca_pend_io().
ca_get() should not be referenced by your
+program until ECA_NORMAL has been received from ca_pend_io().
ca_xxx()
operations that communicate with the server return status indicating the
validity of the request and whether it was successfully enqueued to the server,
but communication of completion status is deferred until a user callback is
@@ -2073,8 +2075,8 @@ called, or lacking that an exception handler is called. An error number and the
error's severity are embedded in CA status (error) constants. Applications
shouldn't test the success of a CA function call by checking to see if the
returned value is zero as is the UNIX convention. Below are several methods to
-test CA function returns. See ca_signal() and SEVCHK
-for more information on this topic.
+test CA function returns. See ca_signal() and
+SEVCHK() for more information on this topic.
status = ca_XXXX(); SEVCHK( status, "ca_XXXX() returned failure status"); @@ -2241,8 +2243,8 @@ integer type, and are functionally equivalent. types. If more than one element is requested, then the individual elements can be accessed in an application program by indexing a pointer to the value field in the DBR_XXX structure. For example, the following code computes the sum of -the elements in a array process variable and prints its time stamp. The dbr_size_n function can be used to determine the correct +the elements in a array process variable and prints its time stamp. The +dbr_size_n()function can be used to determine the correct number of bytes to reserve when there are more than one value field elements in a structured CA data type.#include <stdio.h> @@ -2314,9 +2316,10 @@ int main ( int argc, char ** argv )Certain CA client initiated requests asynchronously execute an application supplied callback in the client process when a response arrives. The functions -ca_put_callback, ca_get_callback, and ca_create_subscription all request notification of -asynchronous completion via this mechanism. The
event_handler_args -structure is passed by value to the application supplied +ca_put_callback(),ca_get_callback(), and +ca_create_subscription()all request notification of +asynchronous completion via this mechanism. Theevent_handler_args+structure is passed by value to the application supplied callback. In this structure thedbrfield is a void pointer to any data that might be returned. Thestatusfield will be set to one of the CA error codes in caerr.h and will indicate the status of the @@ -2325,7 +2328,7 @@ data isn't normally returned from the operation (i.e. put callback) then you should expect that thedbrfield will be set to a null pointer (zero). The fieldsusr,chid, andtypeare set to the values specified when the request was made by the application. -The "dbr" pointer, and any data that it points to, are valid only when +Thedbrpointer, and any data that it points to, are valid only when executing within the user's callback function.typedef struct event_handler_args { void *usr; /* user argument supplied with request */ @@ -2353,16 +2356,16 @@ attached to the request, an exception handler is executed in the client. The default exception handler prints a message on the console and exits if the exception condition is severe. Certain internal exceptions within the CA client library, and failures detected by the SEVCHK macro may also cause the exception -handler to be invoked. To modify this behavior see ca_add_exception_event(). +handler to be invoked. To modify this behavior see +ca_add_exception_event().Server and Client Share the Same Address Space on The Same Host
If the Process Variable's server and it's client are colocated within the -same memory address space and the same host then the ca_xxx() operations bypass +same memory address space and the same host then the
ca_xxx()operations bypass the server and directly interact with the server tool component (commonly the -IOC's function block database). In this situation the ca_xxx() routines +IOC's function block database). In this situation theca_xxx()routines frequently return the completion status of the requested operation directly to the caller with no opportunity for asynchronous notification of failure via an exception handler. Likewise, callbacks may be directly invoked by the CA @@ -2373,7 +2376,7 @@ library functions that request them.For routines that require an argument specifying the number of array elements, no more than the process variable's maximum native element count may be requested. The process variable's maximum native element count is available -from ca_element_count() when the channel is connected. If fewer elements than +from
ca_element_count()when the channel is connected. If fewer elements than the process variable's native element count are requested, the requested values will be fetched beginning at element zero. By default CA limits the number of elements in an array to be no more than approximately 16k divided by the size @@ -2394,20 +2397,20 @@ channel, but should expect that the channel might disconnect at any time due to network connectivity disruptions or server restarts.Three methods can be used to determine if a channel is connected: the -application program might call
@@ -2428,16 +2431,16 @@ enabling preemptive callback should be familiar with using mutex locks to create a reliable multi-threaded program.ca_stateto -obtain the current connection state, block inca_pend_iountil the channel connects, or install -a connection callback handler when it callsca_create_channel. Theca_pend_ioapproach is best suited to simple -command line programs with short runtime duration, and the connection callback -method is best suited to toolkit components with long runtime duration. Use of -ca_stateis appropriate only in programs -that prefer to poll for connection state changes instead of opting for -asynchronous notification. Theca_pend_iofunction blocks only for -channels created specifying a null connection handler callback function. The +application program might callca_state()+to obtain the current connection state, block in +ca_pend_io()until the channel connects, +or install a connection callback handler when it calls +ca_create_channel(). The +ca_pend_io()approach is best suited to +simple command line programs with short runtime duration, and the connection +callback method is best suited to toolkit components with long runtime duration. +Use ofca_state()is appropriate only in +programs that prefer to poll for connection state changes instead of opting for +asynchronous notification. Theca_pend_io()function blocks only +for channels created specifying a null connection handler callback function. The user's connection state change function will be run immediately from within -ca_create_channelif the CA +ca_create_channel()if the CA client and CA server are both hosted within the same address space (within the same process).To set up a traditional single threaded client, you will need code like this -(see ca_context_create and CA Client Contexts and Application Specific Auxiliary +(see
ca_context_create()and +CA Client Contexts and Application Specific Auxiliary Threads) .
SEVCHK ( ca_context_create(ca_disable_preemptive_callback ), "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_create and CA Client Contexts and Application Specific Auxiliary +like this (see
ca_context_create()and +CA Client Contexts and Application Specific Auxiliary Threads).
SEVCHK ( ca_context_create(ca_enable_preemptive_callback ), @@ -2450,31 +2453,31 @@ Threads 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 +ca_context_create()for the first time either directly or implicitly when calling any CA library function 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_attach_context() using the CA context -identifier that was returned from ca_current_context() when it is called by the +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_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 preemptive - it must be created using ca_context_create(ca_enable_preemptive_callback). +be joined must be preemptive - it must be created using +ca_context_create(ca_enable_preemptive_callback). 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 +with a CA context it need only make ordinaryca_xxxx()library calls to use 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 -it, by calling ca_context_destroy(). The +it, by calling
@@ -2483,11 +2486,11 @@ Applicationsca_context_destroy(). The context may be created and destroyed by different threads as long as they are both part of the same context.If preemptive callback is not enabled, then for proper operation CA must periodically be polled to take care of background activity. This requires that -your application must either wait in one of ca_pend_event(), ca_pend_io(), or -ca_sg_block() or alternatively it must call ca_poll() at least every 100 +your application must either wait in one of
ca_pend_event(),ca_pend_io(), or +ca_sg_block()or alternatively it should callca_poll()at least every 100 milliseconds. In single threaded applications a file descriptor manager like Xt or the interface described in fdManager.h can be used to monitor both mouse -clicks and also CA's file descriptors so that ca_poll() can be called +clicks and also CA's file descriptors so thatca_poll()can be called immediately when CA server messages arrives over the network.Avoid Emulating Bad Practices that May Still be @@ -2535,16 +2538,16 @@ questionable practice for the following reasons. saturation situations.
-
- If the code does not call ca_context_destroy (ca_task_exit in past +
- If the code does not call
ca_context_destroy()(namedca_task_exit()in past releases) then resources are left dangling.@@ -2566,7 +2569,7 @@ int ca_context_create ( enum ca_preemptive_callback_select SELECT );
- 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't called, and the vxWorks shell restarted. In +
ca_task_exit()wasn'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 clean up on vxWorks. This + must callca_context_destroy()orca_task_exit()to clean up on vxWorks. This is the same behavior as on all other OS.Description
-This function, or ca_attach_context(), +
This function, or
ca_attach_context(), should be called once from each thread prior to making any of the other Channel Access calls. If one of the above is not called before making other CA calls then a non-preemptive context is created by default, and future attempts to @@ -2574,7 +2577,7 @@ create a preemptive context for the current threads will fail.If
ca_disable_preemptive_callbackis specified then additional threads are not allowed to join the CA context using -ca_context_attach() because allowing other threads to join implies that CA +ca_context_attach()because allowing other threads to join implies that CA callbacks will be called preemptively from more than one thread.Arguments
@@ -2617,7 +2620,7 @@ callback CA context (possibly created implicitly)See Also
- +
ca_context_destroy()#include <cadef.h> @@ -2630,20 +2633,20 @@ resources allocated. Detach the calling thread from any CA client context.Any user-created threads that have attached themselves to the CA context must stop using it prior to its being destroyed. A program running in an IOC -context must delete all of its channels prior to calling ca_context_destroy() +context must delete all of its channels prior to calling
ca_context_destroy()to avoid a crash.A CA client application that calls epicsExit() must install an -EPICS exit handler that calls ca_context_destroy() only after first -calling ca_create_context(). This will guarantee that the EPICS exit handlers +EPICS exit handler that calls
ca_context_destroy()only after first +callingca_create_context(). This will guarantee that the EPICS exit handlers get called in the correct order.On many OS that execute programs in a process based environment the resources used by the client library such as sockets and allocated memory are automatically released by the system when the process exits and -ca_context_destroy() hasn't been called, but on light weight systems such as +
+ca_context_destroy()hasn't been called, but on light weight systems such as vxWorks or RTEMS no cleanup occurs unless the application calls -ca_context_destroy().ca_context_destroy().Returns
@@ -2651,7 +2654,7 @@ ca_context_destroy().See Also
- +
ca_create_channel()#include <cadef.h> @@ -2664,9 +2667,9 @@ int ca_create_channel (const char *PVNAME,This function creates a CA channel. The CA client library will attempt to establish and maintain a virtual circuit between the caller's application and a -named process variable in a CA server. Each call to ca_create_channel allocates +named process variable in a CA server. Each call to
@@ -2681,22 +2684,22 @@ ECA_DISCONNCHID if the channel is currently disconnected.ca_create_channel()allocates resources in the CA client library and potentially also a CA server. The -function ca_clear_channel() is used to release these resources. If successful, +functionca_clear_channel()is used to release these resources. If successful, the routine writes a channel identifier into the user's variable of type "chid". This identifier can be used with any channel access call that operates on a channel.There are two ways to obtain asynchronous notification when a channel enters a connected state.
ca_pend_io(), and
wait for successful completion, prior to using a channel that was created
specifying a null connection callback function pointer.ca_pend_io() will not
block waiting for the channel to enter a connected state.The function ca_state(CHID) can be used to test the connection state of a channel. Valid connections may be isolated from invalid ones with this function -if ca_pend_io() times out.
+ifca_pend_io() times out.
Due to the inherently transient nature of network connections the order of
-connection callbacks relative to the order that ca_create_channel() calls are
+connection callbacks relative to the order that ca_create_channel() calls are
made by the application can't be guaranteed, and application programs may need
to be prepared for a connected channel to enter a disconnected state at any
time.
op field will
be set by the CA client library to CA_OP_CONN_UP when the
channel connects, and to CA_OP_CONN_DOWN when the channel
- disconnects. See ca_puser if the
+ disconnects. See ca_puser() if the
PUSER argument is required in your callback
handler.
struct ca_connection_handler_args {
@@ -2779,11 +2782,11 @@ int ca_clear_channel (chid CHID);
Shutdown and reclaim resources associated with a channel created by -ca_create_channel().
+ca_create_channel().
All remote operation requests such as the above are accumulated (buffered)
-and not forwarded to the IOC until one of ca_flush_io, ca_pend_io,
-ca_pend_event, or ca_sg_pend are called. This allows several requests to be
+and not forwarded to the IOC until one of ca_flush_io(), ca_pend_io(),
+ca_pend_event(), or ca_sg_block() are called. This allows several requests to be
efficiently sent over the network in one message.
Clearing a channel does not cause its disconnect handler to be called, but @@ -2820,11 +2823,11 @@ int ca_array_put_callback ( chtype TYPE, unsigned long COUNT,
Write a scalar or array value to a process variable.
-When ca_put or ca_array_put are invoked the client will receive no response +
When ca_put() or ca_array_put() are invoked the client will receive no response
unless the request can not be fulfilled in the server. If unsuccessful an
exception handler is run on the client side.
When ca_put_callback or ca_array_put_callback are invoked the user supplied +
When ca_put_callback() or ca_array_put_callback() are invoked the user supplied
asynchronous callback is called only after the initiated write operation, and
all actions resulting from the initiating write operation, complete.
All put requests are accumulated (buffered) and not forwarded to the IOC
-until one of ca_flush_io, ca_pend_io, ca_pend_event, or ca_sg_pend are called.
+until one of ca_flush_io(), ca_pend_io(), ca_pend_event(), or ca_sg_block() are called.
This allows several requests to be efficiently combined into one message.
ca_get()#include <cadef.h> @@ -2945,23 +2948,23 @@ int ca_array_get_callback ( chtype TYPE, unsigned long COUNT,Read a scalar or array value from a process variable.
-When ca_get or ca_array_get are invoked the returned channel value can't be +
When
-ca_get()orca_array_get()are invoked the returned channel value can't be assumed to be stable in the application supplied buffer until after ECA_NORMAL -is returned from ca_pend_io. If a connection is lost outstanding ca get +is returned fromca_pend_io(). If a connection is lost outstanding ca get requests are not automatically reissued following reconnect.When ca_get_callback or ca_array_get_callback are invoked a value is read +
When
ca_get_callback()orca_array_get_callback()are invoked a value is read from the channel and then the user's callback is invoked with a pointer to the -retrieved value. Note that ca_pend_io will not block for the delivery of values -requested by ca_get_callback. If the channel disconnects before a ca get -callback request can be completed, then the clients callback function is +retrieved value. Note thatca_pend_io()will not block for the delivery of values +requested byca_get_callback(). If the channel disconnects before a +ca_get_callback()request can be completed, then the client's callback function is called with failure status.All of these functions return ECA_DISCONN if the channel is currently disconnected.
All get requests are accumulated (buffered) and not forwarded to the IOC -until one of ca_flush_io, ca_pend_io, ca_pend_event, or ca_sg_pend are called. +until one of
@@ -2986,7 +2989,7 @@ when a CA get request is initiated.ca_flush_io(),ca_pend_io(),ca_pend_event(), orca_sg_block()are called. This allows several requests to be efficiently sent over the network in one message.
COUNTca_array_get_callback() a count of zero
means use the current element count from the server.ca_create_subscription()#include <cadef.h> @@ -3051,8 +3054,8 @@ significant change can be a change in the process variable's value, alarm status, or alarm severity. In the process control function block database the deadband field determines the magnitude of a significant change for the process variable's value. Each call to this function consumes resources in the -client library and potentially a CA server until one of ca_clear_channel or -ca_clear_subscription is called. +client library and potentially a CA server until one ofca_clear_channel()or +ca_clear_subscription()is called.Subscriptions may be installed or canceled against both connected and disconnected channels. The specified USERFUNC is called once immediately after @@ -3060,7 +3063,7 @@ the subscription is installed with the process variable's current state if the process variable is connected. Otherwise, the specified USERFUNC is called immediately after establishing a connection (or reconnection) with the process variable. The specified USERFUNC is called immediately with the process -variable's current state from within ca_create_subscription() if the client and the +variable's current state from within
ca_create_subscription()if the client and the process variable share the same address space.If a subscription is installed on a channel in a disconnected state then the @@ -3068,8 +3071,8 @@ requested count will be set to the native maximum element count of the channel if the requested count is larger.
All subscription requests such as the above are accumulated (buffered) and -not forwarded to the IOC until one of ca_flush_io, ca_pend_io, ca_pend_event, -or ca_sg_pend are called. This allows several requests to be efficiently sent +not forwarded to the IOC until one of
ca_flush_io(),ca_pend_io(),ca_pend_event(), +orca_sg_block()are called. This allows several requests to be efficiently sent over the network in one message.If at any time after subscribing, read access to the specified process @@ -3078,7 +3081,7 @@ that read access was lost via the status argument. When read access is restored normal event processing will resume starting always with at least one update indicating the current state of the channel.
-A better name for this function might have been ca_subscribe.
+A better name for this function might have been
ca_subscribe().Example
@@ -3154,9 +3157,9 @@ indicating the current state of the channel.See Also
- + - +
ca_clear_subscription()#include <cadef.h> @@ -3167,8 +3170,8 @@ int ca_clear_subscription ( evid EVID );Cancel a subscription.
All cancel-subscription requests such as the above are accumulated (buffered) -and not forwarded to the server until one of ca_flush_io, ca_pend_io, -ca_pend_event, or ca_sg_pend are called. This allows several requests to be +and not forwarded to the server until one of
ca_flush_io(),ca_pend_io(), +ca_pend_event(), orca_sg_block()are called. This allows several requests to be efficiently sent together in one message.Arguments
@@ -3185,7 +3188,7 @@ efficiently sent together in one message.See Also
- +
ca_pend_io()#include <cadef.h> @@ -3193,39 +3196,39 @@ int ca_pend_io ( double TIMEOUT );Description
-This function flushes the send buffer and then blocks until outstanding ca_get requests complete, and until channels created +
This function flushes the send buffer and then blocks until outstanding +
ca_get()requests complete, and until channels created specifying null connection handler function pointers connect for the first time.
ca_get() requests have completed
successfully and channels created specifying null connection handler
function pointers have connected for the first time.ca_get() requests and properly qualified first time
channel connects have failed.If ECA_TIMEOUT is returned then get requests may be reissued followed by a
-subsequent call to ca_pend_io(). Specifically, the function will block only for
-outstanding ca_get requests issued, and also any channels
+subsequent call to ca_pend_io(). Specifically, the function will block only for
+outstanding ca_get() requests issued, and also any channels
created specifying a null connection handler function pointer, after the last
-call to ca_pend_io() or ca client context creation whichever is later. Note
-that ca_create_channel requests generally
-should not be reissued for the same process variable unless ca_clear_channel is called first.
ca_pend_io() or ca client context creation whichever is later. Note
+that ca_create_channel() requests generally
+should not be reissued for the same process variable unless
+ca_clear_channel() is called first.
-If no ca_get or connection state change events are -outstanding then ca_pend_io() will flush the send buffer and return immediately +
If no ca_get() or connection state change events are
+outstanding then ca_pend_io() will flush the send buffer and return immediately
without processing any outstanding channel access background
activities.
The delay specified to ca_pend_io() should take into account worst case +
The delay specified to ca_pend_io() should take into account worst case
network delays such as Ethernet collision exponential back off until
retransmission delays which can be quite long on overloaded networks.
Unlike ca_pend_event, this routine
+
Unlike ca_pend_event(), this routine
will not process CA's background activities if none of the selected IO requests
are pending.
ca_get()
+ca_get()
ca_test_io()#include <cadef.h> @@ -3259,11 +3262,11 @@ int ca_test_io();
This function tests to see if all ca_get requests are +
This function tests to see if all ca_get() requests are
complete and channels created specifying a null connection callback function
-pointer are connected. It will report the status of outstanding ca_get requests issued, and channels created specifying a
-null connection callback function pointer, after the last call to ca_pend_io()
+pointer are connected. It will report the status of outstanding
+ca_get() requests issued, and channels created specifying a
+null connection callback function pointer, after the last call to ca_pend_io()
or CA context initialization whichever is later.
ca_pend_event()#include <cadef.h> @@ -3283,19 +3286,19 @@ int ca_poll ();
When ca_pend_event is invoked the send buffer is flushed and CA background +
When ca_pend_event() is invoked the send buffer is flushed and CA background
activity is processed for TIMEOUT seconds.
When ca_poll is invoked the send buffer is flushed and any outstanding CA +
When ca_poll() is invoked the send buffer is flushed and any outstanding CA
background activity is processed.
The ca_pend_event function will not return before the specified +
The ca_pend_event() function will not return before the specified
timeout expires and all unfinished channel access labor has been processed,
-and unlike ca_pend_io returning from the
+and unlike ca_pend_io() returning from the
function does not indicate anything about the status of pending IO
requests.
Both ca_pend_event and ca_poll return ECA_TIMEOUT
+
Both ca_pend_event() and ca_poll() return ECA_TIMEOUT
when successful. This behavior probably isn't intuitive, but it is preserved to
insure backwards compatibility.
SEVCHK is a macro envelope around ca_signal which only calls ca_signal() if +
SEVCHK is a macro envelope around ca_signal() which only calls ca_signal() if
the supplied error code indicates an unsuccessful operation. SEVCHK is the
recommended error handler for simple applications which do not wish to write
code testing the status returned from each channel access call.
ca_pend_event() periodically. It would probably not be appropriate
to use this function with preemptive callback mode. Starting with R3.14 this
function is implemented in a special backward compatibility mode. if
-ca_add_fd_registration is called, a single pseudo UDP fd is
+ca_add_fd_registration() is called, a single pseudo UDP fd is
created which CA pokes whenever something significant happens. Xt and others
can watch this fd so that backwards compatibility is preserved, and so that
they will not need to use preemptive callback mode but they will nevertheless
@@ -3876,7 +3879,7 @@ extern unsigned dbr_value_size[/* TYPE */];
The array dbr_value_size[TYPE] returns the size in bytes for the value +
The array dbr_value_size[TYPE] returns the size in bytes for the value
stored in a DBR_XXXX type. If the type is a structure the size of the value
field is returned otherwise the size of the type is returned.
ca_sg_create()#include <cadef.h> @@ -3943,10 +3946,10 @@ int ca_sg_create ( CA_SYNC_GID *PGID );
A synchronous group can be used to guarantee that a set of channel access
requests have completed. Once a synchronous group has been created then channel
-access get and put requests may be issued within it using ca_sg_get() and
-ca_sg_put() respectively. The routines ca_sg_block() and ca_sg_test() can be
+access get and put requests may be issued within it using ca_sg_get() and
+ca_sg_put() respectively. The routines ca_sg_block() and ca_sg_test() can be
used to block for and test for completion respectively. The routine
-ca_sg_reset() is used to discard knowledge of old requests which have timed out
+ca_sg_reset() is used to discard knowledge of old requests which have timed out
and in all likelihood will never be satisfied.
Any number of asynchronous groups can have application requested operations @@ -3971,17 +3974,17 @@ SEVCHK ( status, Sync group create failed );
ca_sg_delete()#include <cadef.h> @@ -4010,7 +4013,7 @@ SEVCHK ( status, Sync group delete failed );
ca_sg_block()#include <cadef.h> @@ -4020,17 +4023,17 @@ int ca_sg_block ( CA_SYNC_GID GID, double TIMEOUT );
Flushes the send buffer and then waits until outstanding requests complete
or the specified time out expires. At this time outstanding requests include
-calls to ca_sg_array_get() and calls to ca_sg_array_put(). If ECA_TIMEOUT is
+calls to ca_sg_array_get() and calls to ca_sg_array_put(). If ECA_TIMEOUT is
returned then failure must be assumed for all outstanding queries. Operations
-can be reissued followed by another ca_sg_block(). This routine will only block
-on outstanding queries issued after the last call to ca_sg_block(),
-ca_sg_reset(), or ca_sg_create() whichever occurs later in time. If no queries
-are outstanding then ca_sg_block() will return immediately without processing
+can be reissued followed by another ca_sg_block(). This routine will only block
+on outstanding queries issued after the last call to ca_sg_block(),
+ca_sg_reset(), or ca_sg_create() whichever occurs later in time. If no queries
+are outstanding then ca_sg_block() will return immediately without processing
any pending channel access activities.
Values written into your program's variables by a channel access synchronous
group request should not be referenced by your program until ECA_NORMAL has
-been received from ca_sg_block(). This routine will process pending channel
+been received from ca_sg_block(). This routine will process pending channel
access background activity while it is waiting.
ca_sg_test()#include <cadef.h> @@ -4100,7 +4103,7 @@ int ca_sg_reset ( CA_SYNC_GID GID )
Reset the number of outstanding requests within the specified synchronous
-group to zero so that ca_sg_test() will return ECA_IODONE and ca_sg_block()
+group to zero so that ca_sg_test() will return ECA_IODONE and ca_sg_block()
will not block unless additional subsequent requests are made.
Write a value, or array of values, to a channel and increment the -outstanding request count of a synchronous group. The ca_sg_array_put -functionality is implemented using ca_array_put_callback.
+outstanding request count of a synchronous group. Theca_sg_array_put()
+functionality is implemented using ca_array_put_callback().
All remote operation requests such as the above are accumulated (buffered)
-and not forwarded to the server until one of ca_flush_io(), ca_pend_io(),
-ca_pend_event(), or ca_sg_pend() are called. This allows several requests to be
+and not forwarded to the server until one of ca_flush_io(), ca_pend_io(),
+ca_pend_event(), or ca_sg_block() are called. This allows several requests to be
efficiently sent in one message.
If a connection is lost and then resumed outstanding puts are not @@ -4179,7 +4182,7 @@ reissued.
ca_sg_array_get()#include <cadef.h> @@ -4190,16 +4193,16 @@ int ca_sg_array_get ( CA_SYNC_GID GID,Description
Read a value from a channel and increment the outstanding request count of a -synchronous group. The ca_sg_array_get functionality is implemented using -ca_array_get_callback.
+synchronous group. Theca_sg_array_get()functionality is implemented using +ca_array_get_callback(). -The values written into your program's variables by ca_sg_get should not be -referenced by your program until ECA_NORMAL has been received from ca_sg_block, -or until ca_sg_test returns ECA_IODONE.
+The values written into your program's variables by
ca_sg_get()should not be +referenced by your program until ECA_NORMAL has been received fromca_sg_block(), +or untilca_sg_test()returns ECA_IODONE.All remote operation requests such as the above are accumulated (buffered) -and not forwarded to the server until one of ca_flush_io, ca_pend_io, -ca_pend_event, or ca_sg_pend are called. This allows several requests to be +and not forwarded to the server until one of
ca_flush_io(),ca_pend_io(), +ca_pend_event(), orca_sg_block()are called. This allows several requests to be efficiently sent in one message.If a connection is lost and then resumed outstanding gets are not @@ -4247,11 +4250,11 @@ reissued.
See Also
- + - + - +
ca_client_status()int ca_client_status ( unsigned level ); @@ -4262,7 +4265,7 @@ int ca_context_status ( struct ca_client_context *CONTEXT,Prints information about the client context including, at higher interest levels, status for each channel. Lacking a CA context pointer, -ca_client_status() prints information about the calling threads CA context.
+ca_client_status()prints information about the calling threads CA context.Arguments
ca_attach_context()int ca_attach_context (struct ca_client_context *CONTEXT);@@ -4297,7 +4300,7 @@ returned.
The calling thread becomes a member of the specified CA context. If
ca_disable_preemptive_callback is specified when
-ca_context_create() is called (or if ca_task_initialize() is called) then
+ca_context_create() is called (or if ca_task_initialize() is called) then
additional threads are not allowed to join the CA context because
allowing other threads to join implies that CA callbacks will be called
preemptively from more than one thread.
ca_detach_context()void ca_detach_context();@@ -4333,17 +4336,17 @@ preemptively from more than one thread.
Detach from any CA context currently attached to the calling thread. This does not cleanup or shutdown any currently attached CA context (for -that use ca_context_destroy).
+that useca_context_destroy()).
ca_dump_dbr()void ca_dump_dbr (chtype TYPE, unsigned COUNT, const void * PDBR);