Shut down a channel access client context and free any resources
allocated. On most operating systems this is performed automatically at
process exit.
@@ -1365,9 +1372,9 @@ call that operates on a channel.
The circuit may be initially connected or disconnected depending on the
state of the network and the location of the channel. A channel will
-only enter a connected state after server's address is determined, and only
-if channel access successfully establishes a virtual circuit through the
-network to the server. Channel access routines that send a request to a
+only enter a connected state after server's address is determined,
+and only if channel access successfully establishes a virtual circuit through
+the network to the server. Channel access routines that send a request to a
server will return ECA_DISCONNCHID if the channel is currently
disconnected.
@@ -1405,9 +1412,9 @@ any time.
PRIORITYDescription
-Shutdown and reclaim resources associated with a channel created by
+
Shutdown and reclaim resources associated with a channel created by
ca_create_channel().
All remote operation requests such as the above are accumulated (buffered)
@@ -1482,7 +1489,7 @@ efficiently sent over the network in one message.
Clearing a channel does not cause its disconnect handler to be called, but
clearing a channel does shutdown and reclaim any channel state change event
-subscriptions (monitors) registered with the channel.
+subscriptions (monitors) registered with the channel.
Arguments
@@ -1516,17 +1523,17 @@ int ca_array_put_callback ( chtype TYPE,
Write a scalar or array value to a process variable.
-When ca_array_put or ca_put are invoked the client will receive no
+
When ca_array_put or ca_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. If a connection
-is lost and then resumed outstanding ca_array_put or ca_put requests are
-not automatically reissued following reconnect, and no additional
-notification are provided to the user for each put request.
+is lost and then resumed outstanding ca_array_put or ca_put
+requests are not automatically reissued following reconnect, and no
+additional notification are provided to the user for each put request.
When ca_array_put_callback are invoked the user supplied asynchronous call
-back is called only after the initiated write operation and all actions
-resulting from the initiating write operation complete. If unsuccessful the
-call back function is invoked indicating bad status. If the channel
+back is called only after the initiated write operation and all actions
+resulting from the initiating write operation complete. If unsuccessful
+the call back function is invoked indicating bad status. If the channel
disconnects before a put callback request can be completed, then the client's
call back function is called with bad status, but this does not guarantee
that the server did not receive and process the request before the
@@ -1563,8 +1570,8 @@ message.
PFUNC- address of user supplied callback function to be
- run when the requested operation completes
+ - address of user supplied callback function
+ to be run when the requested operation completes
USERARGAll of these functions return ECA_DISCONN if the channel is currently
disconnected.
@@ -1711,26 +1718,27 @@ int ca_add_masked_array_event ( chtype TYPE,
Description
Register a state change subscription and specify a call back function to
-be invoked whenever the process variable undergoes significant state changes.
-A 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 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_event is called.
+be invoked whenever the process variable undergoes significant
+state changes. A 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 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_event is called.
-Subscriptions may be installed or canceled against both connected and
-disconnected channels. The specified USERFUNC is called once immediately
-after 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_add_event() if the client and
-the process variable share the same address space.
+Subscriptions may be installed or canceled against both
+connected and disconnected channels. The specified USERFUNC is called once
+immediately after 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_add_event() 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 requested count will be set to the native maximum element count of the
-channel if the requested count is larger.
+If a subscription is installed on a channel in a disconnected state
+then the 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,
@@ -1739,9 +1747,9 @@ over the network in one message.
If at any time after subscribing, read access to the specified process
variable is lost, then the call back will be invoked immediately indicating
-that read access was lost via the status argument. When read access is
+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.
+least one update indicating the current state of the channel.
A better name for this function might have been ca_subscribe.
@@ -1767,8 +1775,9 @@ least
USRERFUNC- The address of user supplied callback function to
- be invoked with each subscription update.
+ - The address of user supplied
+ callback function to be invoked with each subscription
+ update.
USERARGPEVID- This is a pointer to user supplied event id which is overwritten if
successful. This event id can later be used to clear a specific
- event. This option may may be omitted by passing a nil pointer.
+ event. This option may may be omitted by passing a nil
+ pointer.
MASKCancel a subscription.
All ca_clear_event() requests such as the above are accumulated (buffered)
-and not forwarded to the server until one of ca_flush_io, ca_pend_io,
+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
efficiently sent together in one message.
@@ -1869,19 +1879,19 @@ time.
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 outstanding ca_get requests issued, and
-also any channels created specifying a nill connection handler function
-pointer, after the last call to ca_pend_io() or ca client context creation
-whichever is later. Note that ca_get
+requests issued, and also any channels created specifying a nill 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 should not be
reissued 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 without processing any outstanding channel access background
-activities.
+immediately without processing any outstanding channel access
+background activities.
The delay specified to ca_pend_io() should take into account worst case
network delays such as Ethernet collision exponential back off until
@@ -1895,7 +1905,7 @@ are pending.
- TIMEOUT
- Specifies the time out interval. A
TIMEOUT interval of
- zero specifies forever.
+ zero specifies forever.
Returns
@@ -1920,12 +1930,13 @@ int ca_test_io();
Description
-This function tests to see if all ca_get requests
-are complete and channels created specifying a nill connection callback
-function pointer are connected. It will report the status of outstanding ca_get requests issued, and channels created specifying a
-nill connection callback function pointer, after the last call to
-ca_pend_io() or CA context initialization whichever is later.
+This function tests to see if all ca_get
+requests are complete and channels created specifying a nill connection
+callback function pointer are connected. It will report the status of
+outstanding ca_get requests issued, and channels
+created specifying a nill connection callback function pointer, after the
+last call to ca_pend_io() or CA context initialization whichever is
+later.
Returns
@@ -1978,9 +1989,10 @@ int ca_flush_io();
Description
-Flush outstanding IO requests to the server. This routine might be useful
-to users who need to flush requests prior to performing client side labor in
-parallel with labor performed in the server.
+Flush outstanding IO requests to the server. This routine might
+be useful to users who need to flush requests prior
+to performing client side labor in parallel with labor performed in the
+server.
Outstanding requests are also sent whenever the buffer which holds them
becomes full.
@@ -2022,7 +2034,7 @@ for this purpose.
CONTEXT_STRING- A null terminated character string to supply as error context to
+
- A null terminated character string to supply as error context to
diagnostics.
@@ -2043,10 +2055,10 @@ back.
When an error occurs in the server asynchronous to the clients thread then
information about this type of error is passed from the server to the client
-in an exception message. When the client receives this exception message an
-exception handler callback is called.The default exception handler prints a
-diagnostic message on the client's standard out and terminates execution if
-the error condition is severe.
+in an exception message. When the client receives this exception message
+an exception handler callback is called.The default exception handler prints
+a diagnostic message on the client's standard out and terminates
+execution if the error condition is severe.
Note that certain fields in "struct exception_handler_args" are not
applicable in the context of some error messages. For instance, a failed get
@@ -2161,7 +2173,7 @@ specified channel.
When a channel is created no access rights handler is installed.
+When a channel is created no access rights handler is installed.