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

CAref reformatting/prettification

Browse Source
This commit is contained in:
Andrew Johnson
2014-11-08 10:19:59 -06:00
parent 702edbf4af
commit 3d03822043
1 changed files with 188 additions and 185 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/ca/CAref.html
+188 -185
View File
@@ -835,8 +835,8 @@ the same UDP port on the same host</a>.</p>
<p>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 <a href="#Disconnect">EPICS_CA_CONN_TMO</a> and <a
href="#Dynamic">Dynamic Changes in the CA Client Library Search
seconds. See also <a href="#Disconnect">EPICS_CA_CONN_TMO</a> and
<a href="#Dynamic">Dynamic Changes in the CA Client Library Search
Interval</a>.</p>
<p>CA servers build a list of addresses to send beacons to during
@@ -1598,7 +1598,7 @@ command line is used.</p>
stdout.</p>
<p>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 <code>ca_client_status()</code>, that prints lots of
internal informations on stdout, including environment settings, used CA ports
etc.</p>
@@ -1964,7 +1964,8 @@ OS and even between different versions of the same OS.</p>
or the network's sustained event consumption rate. This ties up a per
socket quota of mbufs for data that are pending transmission to the client
via the network. In particular, if there are multiple clients that
subscribe for monitor events but do not call ca_pend_event() or ca_poll()
subscribe for monitor events but do not call <code>ca_pend_event()</code>
or <code>ca_poll()</code>
to process their CA input queue, then a significant mbuf consuming backlog
can occur in the server.</li>
</ul>
@@ -2052,11 +2053,12 @@ example, be beneficial when tuning an archiver installation.</p>
<p>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 <code>ca_flush_io()</code>,
<code>ca_pend_io()</code>, <code>ca_pend_event()</code>, or
<code>ca_sg_block()</code> 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().</p>
into your program's variables by <code>ca_get()</code> should not be referenced by your
program until ECA_NORMAL has been received from <code>ca_pend_io()</code>.</p>
<h3><a name="Status">Status Codes</a></h3>
@@ -2065,7 +2067,7 @@ ECA_NORMAL. Unsuccessful status codes returned from the client library are
listed with each routine in this manual. Operations that appear to be valid to
the client can still fail in the server. Writing the string "off" to a floating
point field is an example of this type of error. If the server for a channel is
located in a different address space than the client then the ca_xxx()
located in a different address space than the client then the <code>ca_xxx()</code>
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 <a href="#ca_signal">ca_signal() and SEVCHK</a>
for more information on this topic.</p>
test CA function returns. See <a href="#ca_signal"><code>ca_signal()</code> and
<code>SEVCHK()</code></a> for more information on this topic.</p>
<pre>status = ca_XXXX();
SEVCHK( status, "ca_XXXX() returned failure status");
@@ -2241,8 +2243,8 @@ integer type, and are functionally equivalent.</p>
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 <a
href="#dbr_size_n">dbr_size_n</a> function can be used to determine the correct
the elements in a array process variable and prints its time stamp. The
<code><a href="#dbr_size_n">dbr_size_n</a>()</code> 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.</p>
<pre>#include &lt;stdio.h&gt;
@@ -2314,9 +2316,10 @@ int main ( int argc, char ** argv )
<p>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 <code>event_handler_args
</code>structure is passed <em>by value</em> to the application supplied
<code>ca_put_callback()</code>, <code>ca_get_callback()</code>, and
<code>ca_create_subscription()</code> all request notification of
asynchronous completion via this mechanism. The <code>event_handler_args</code>
structure is passed <em>by value</em> to the application supplied
callback. In this structure the <code>dbr</code> field is a void pointer to any
data that might be returned. The <code>status</code> field 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 the <code>dbr</code> field will be set to a null pointer
(zero). The fields <code>usr</code>, <code>chid</code>, and <code>type</code>
are 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
The <code>dbr</code> pointer, and any data that it points to, are valid only when
executing within the user's callback function.</p>
<pre>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 <a
href="#ca_add_exception_event">ca_add_exception_event()</a>.</p>
handler to be invoked. To modify this behavior see
<code><a href="#ca_add_exception_event">ca_add_exception_event</a>()</code>.</p>
<h3><a name="Server">Server and Client Share the Same Address Space on The Same
Host</a></h3>
<p>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 <code>ca_xxx()</code> 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 the <code>ca_xxx()</code> 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.</p>
<p>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 <code>ca_element_count()</code> 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.</p>
<p>Three methods can be used to determine if a channel is connected: the
application program might call <a href="#ca_state"><code>ca_state</code></a> to
obtain the current connection state, block in <code><a
href="#ca_pend_io">ca_pend_io</a></code> until the channel connects, or install
a connection callback handler when it calls <code><a
href="#ca_create_channel">ca_create_channel</a></code>. The <code><a
href="#ca_pend_io">ca_pend_io</a></code> 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 of
<code><a href="#ca_state">ca_state</a></code> is appropriate only in programs
that prefer to poll for connection state changes instead of opting for
asynchronous notification. The <code>ca_pend_io</code> function blocks only for
channels created specifying a null connection handler callback function. The
application program might call <code><a href="#ca_state">ca_state</a>()</code>
to obtain the current connection state, block in
<code><a href="#ca_pend_io">ca_pend_io</a>()</code> until the channel connects,
or install a connection callback handler when it calls
<code><a href="#ca_create_channel">ca_create_channel</a>()</code>. The
<code><a href="#ca_pend_io">ca_pend_io</a>()</code> 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 of <code><a href="#ca_state">ca_state</a>()</code> is appropriate only in
programs that prefer to poll for connection state changes instead of opting for
asynchronous notification. The <code>ca_pend_io()</code> 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
<code><a href="#ca_create_channel">ca_create_channel</a></code> if the CA
<code><a href="#ca_create_channel">ca_create_channel</a>()</code> if the CA
client and CA server are both hosted within the same address space (within the
same process).</p>
@@ -2428,16 +2431,16 @@ enabling preemptive callback should be familiar with using mutex locks to
create a reliable multi-threaded program.</p>
<p>To set up a traditional single threaded client, you will need code like this
(see <a href="#ca_context_create">ca_context_create</a> and <a
href="#Client2">CA Client Contexts and Application Specific Auxiliary
(see <code><a href="#ca_context_create">ca_context_create</a>()</code> and
<a href="#Client2">CA Client Contexts and Application Specific Auxiliary
Threads</a>) .</p>
<p><code>SEVCHK ( ca_context_create(ca_disable_preemptive_callback ),
"application pdq calling ca_context_create" );</code></p>
<p>To set up a preemptive callback enabled CA client context you will need code
like this (see <a href="#ca_context_create">ca_context_create</a> and <a
href="#Client2">CA Client Contexts and Application Specific Auxiliary
like this (see <code><a href="#ca_context_create">ca_context_create</a>()</code> and
<a href="#Client2">CA Client Contexts and Application Specific Auxiliary
Threads</a>).</p>
<p><code>SEVCHK ( ca_context_create(ca_enable_preemptive_callback ),
@@ -2450,31 +2453,31 @@ Threads</a></h3>
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
<a href="#ca_context_create">ca_context_create()</a> for the first time either
<code><a href="#ca_context_create">ca_context_create</a>()</code> 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 <a
href="#ca_context_create">ca_context_create()</a>. An application specific
auxiliary thread can join a CA context by calling <a
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
offsets from the priority of the thread that called
<code><a href="#ca_context_create">ca_context_create</a>()</code>. An application specific
auxiliary thread can join a CA context by calling
<code><a href="#ca_attach_context">ca_attach_context</a>()</code> using the CA context
identifier that was returned from
<code><a href="#ca_current_context">ca_current_context</a>()</code> 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 <a
href="#ca_context_create">ca_context_create(ca_enable_preemptive_callback)</a>.
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 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
with a CA context it need only make ordinary <code>ca_xxxx()</code> library calls to use 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
it, by calling <a href="#ca_context_destroy">ca_context_destroy()</a>. The
it, by calling <code><a href="#ca_context_destroy">ca_context_destroy</a>()</code>. The
context may be created and destroyed by different threads as long as they are
both part of the same context.</p>
@@ -2483,11 +2486,11 @@ Applications</a></h3>
<p>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 <code>ca_pend_event()</code>, <code>ca_pend_io()</code>, or
<code>ca_sg_block()</code> or alternatively it should call <code>ca_poll()</code> 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 that <code>ca_poll()</code> can be called
immediately when CA server messages arrives over the network.</p>
<h3><a name="Avoid">Avoid Emulating Bad Practices that May Still be
@@ -2535,16 +2538,16 @@ questionable practice for the following reasons.</p>
saturation situations.</li>
</ul>
<ul>
<li>If the code does not call ca_context_destroy (ca_task_exit in past
<li>If the code does not call <code>ca_context_destroy()</code> (named <code>ca_task_exit()</code> in past
releases) then resources are left dangling.</li>
</ul>
<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't called, and the vxWorks shell restarted. In
<code>ca_task_exit()</code> 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 call <code>ca_context_destroy()</code> or <code>ca_task_exit()</code> to clean up on vxWorks. This
is the same behavior as on all other OS.</li>
</ul>
@@ -2566,7 +2569,7 @@ int ca_context_create ( enum ca_preemptive_callback_select SELECT );</pre>
<h4>Description</h4>
<p>This function, or <a href="#ca_attach_context">ca_attach_context()</a>,
<p>This function, or <code><a href="#ca_attach_context">ca_attach_context</a>()</code>,
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.</p>
<p>If <code>ca_disable_preemptive_callback</code> is specified then additional
threads are <em>not</em> allowed to join the CA context using
ca_context_attach() because allowing other threads to join implies that CA
<code>ca_context_attach()</code> because allowing other threads to join implies that CA
callbacks will be called preemptively from more than one thread.</p>
<h4>Arguments</h4>
@@ -2617,7 +2620,7 @@ callback CA context (possibly created implicitly)</p>
<h4>See Also</h4>
<p><a href="#ca_context_destroy">ca_context_destroy</a>()</p>
<p><code><a href="#ca_context_destroy">ca_context_destroy</a>()</code></p>
<h3><code><a name="ca_context_destroy">ca_context_destroy()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -2630,20 +2633,20 @@ resources allocated. Detach the calling thread from any CA client context.</p>
<p>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 <code>ca_context_destroy()</code>
to avoid a crash.</p>
<p>A CA client application that calls epicsExit() <em>must</em> install an
EPICS exit handler that calls ca_context_destroy() only <em>after</em> first
calling ca_create_context(). This will guarantee that the EPICS exit handlers
EPICS exit handler that calls <code>ca_context_destroy()</code> only <em>after</em> first
calling <code>ca_create_context()</code>. This will guarantee that the EPICS exit handlers
get called in the correct order.</p>
<p>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
<code>ca_context_destroy()</code> hasn't been called, but on light weight systems such as
vxWorks or RTEMS no cleanup occurs unless the application calls
ca_context_destroy().</p>
<code>ca_context_destroy()</code>.</p>
<h4>Returns</h4>
@@ -2651,7 +2654,7 @@ ca_context_destroy().</p>
<h4>See Also</h4>
<p><a href="#ca_context_create">ca_context_create</a>()</p>
<p><code><a href="#ca_context_create">ca_context_create</a>()</code></p>
<h3><code><a name="ca_create_channel">ca_create_channel()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -2664,9 +2667,9 @@ int ca_create_channel (const char *PVNAME,
<p>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 <code>ca_create_channel()</code> 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,
function <code>ca_clear_channel()</code> 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.</p>
@@ -2681,22 +2684,22 @@ ECA_DISCONNCHID if the channel is currently disconnected.</p>
<p>There are two ways to obtain asynchronous notification when a channel enters
a connected state.</p>
<ul>
<li>The first and simplest method requires that you call ca_pend_io(), and
<li>The first and simplest method requires that you call <code>ca_pend_io()</code>, and
wait for successful completion, prior to using a channel that was created
specifying a null connection callback function pointer.</li>
<li>The second method requires that you register a connection handler by
supplying a valid connection callback function pointer. This connection
handler is called whenever the connection state of the channel changes. If
you have installed a connection handler then ca_pend_io() will <em>not</em>
you have installed a connection handler then <code>ca_pend_io()</code> will <em>not</em>
block waiting for the channel to enter a connected state.</li>
</ul>
<p>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.</p>
if <code>ca_pend_io()</code> times out.</p>
<p>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 <code>ca_create_channel()</code> 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.</p>
@@ -2725,7 +2728,7 @@ time.</p>
connection callback function. The <code>op</code> field will
be set by the CA client library to <code>CA_OP_CONN_UP</code> when the
channel connects, and to <code>CA_OP_CONN_DOWN</code> when the channel
disconnects. See <code><a href="#ca_puser">ca_puser</a></code> if the
disconnects. See <code><a href="#ca_puser">ca_puser</a>()</code> if the
<code>PUSER</code> argument is required in your callback
handler<code>.</code></p>
<pre>struct ca_connection_handler_args {
@@ -2779,11 +2782,11 @@ int ca_clear_channel (chid CHID);</pre>
<h4>Description</h4>
<p>Shutdown and reclaim resources associated with a channel created by
ca_create_channel().</p>
<code>ca_create_channel()</code>.</p>
<p>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 <code>ca_flush_io()</code>, <code>ca_pend_io()</code>,
<code>ca_pend_event()</code>, or <code>ca_sg_block()</code> are called. This allows several requests to be
efficiently sent over the network in one message.</p>
<p>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,
<p>Write a scalar or array value to a process variable.</p>
<p>When ca_put or ca_array_put are invoked the client will receive no response
<p>When <code>ca_put()</code> or <code>ca_array_put()</code> 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.</p>
<p>When ca_put_callback or ca_array_put_callback are invoked the user supplied
<p>When <code>ca_put_callback()</code> or <code>ca_array_put_callback()</code> 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.</p>
@@ -2841,7 +2844,7 @@ put requests are not automatically reissued following reconnect.</p>
disconnected.</p>
<p>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 <code>ca_flush_io()</code>, <code>ca_pend_io()</code>, <code>ca_pend_event()</code>, or <code>ca_sg_block()</code> are called.
This allows several requests to be efficiently combined into one message.</p>
<h4>Description (IOC Database Specific)</h4>
@@ -2921,11 +2924,11 @@ but they do not cause the record to be processed.</p>
<h4>See Also</h4>
<p><a href="#ca_flush_io">ca_flush_io</a>()</p>
<p><code><a href="#ca_flush_io">ca_flush_io</a>()</code></p>
<p><a href="#ca_pend_event">ca_pend_event</a>()</p>
<p><code><a href="#ca_pend_event">ca_pend_event</a>()</code></p>
<p><a href="#ca_sg_put">ca_sg_array_put</a>()</p>
<p><code><a href="#ca_sg_put">ca_sg_array_put</a>()</code></p>
<h3><code><a name="ca_get">ca_get()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -2945,23 +2948,23 @@ int ca_array_get_callback ( chtype TYPE, unsigned long COUNT,
<p>Read a scalar or array value from a process variable.</p>
<p>When ca_get or ca_array_get are invoked the returned channel value can't be
<p>When <code>ca_get()</code> or <code>ca_array_get()</code> 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 from <code>ca_pend_io()</code>. If a connection is lost outstanding ca get
requests are not automatically reissued following reconnect.</p>
<p>When ca_get_callback or ca_array_get_callback are invoked a value is read
<p>When <code>ca_get_callback()</code> or <code>ca_array_get_callback()</code> 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 that <code>ca_pend_io()</code> will not block for the delivery of values
requested by <code>ca_get_callback()</code>. If the channel disconnects before a
<code>ca_get_callback()</code> request can be completed, then the client's callback function is
called with failure status.</p>
<p>All of these functions return ECA_DISCONN if the channel is currently
disconnected.</p>
<p>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 <code>ca_flush_io()</code>, <code>ca_pend_io()</code>, <code>ca_pend_event()</code>, or <code>ca_sg_block()</code> are called.
This allows several requests to be efficiently sent over the network in one
message.</p>
@@ -2986,7 +2989,7 @@ when a CA get request is initiated.</p>
<dl>
<dt><code>COUNT</code></dt>
<dd>Element count to be read from the specified channel. Must match the
array pointed to by PVALUE. For ca_array_get_callback a count of zero
array pointed to by PVALUE. For <code>ca_array_get_callback()</code> a count of zero
means use the current element count from the server.</dd>
</dl>
<dl>
@@ -3029,11 +3032,11 @@ when a CA get request is initiated.</p>
<h4>See Also</h4>
<p><a href="#ca_pend_io">ca_pend_io</a>()</p>
<p><code><a href="#ca_pend_io">ca_pend_io</a>()</code></p>
<p><a href="#ca_pend_event">ca_pend_event</a>()</p>
<p><code><a href="#ca_pend_event">ca_pend_event</a>()</code></p>
<p><a href="#ca_sg_get">ca_sg_array_get</a>()</p>
<p><code><a href="#ca_sg_get">ca_sg_array_get</a>()</code></p>
<h3><code><a name="ca_add_event">ca_create_subscription()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -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.</p>
client library and potentially a CA server until one of <code>ca_clear_channel()</code> or
<code>ca_clear_subscription()</code> is called.</p>
<p>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 <code>ca_create_subscription()</code> if the client and the
process variable share the same address space.</p>
<p>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.</p>
<p>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 <code>ca_flush_io()</code>, <code>ca_pend_io()</code>, <code>ca_pend_event()</code>,
or <code>ca_sg_block()</code> are called. This allows several requests to be efficiently sent
over the network in one message.</p>
<p>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.</p>
<p>A better name for this function might have been ca_subscribe.</p>
<p>A better name for this function might have been <code>ca_subscribe()</code>.</p>
<h4>Example</h4>
@@ -3154,9 +3157,9 @@ indicating the current state of the channel.</p>
<h4>See Also</h4>
<p><a href="#ca_pend_event">ca_pend_event</a>()</p>
<p><code><a href="#ca_pend_event">ca_pend_event</a>()</code></p>
<p><a href="#ca_flush_io">ca_flush_io</a>()</p>
<p><code><a href="#ca_flush_io">ca_flush_io</a>()</code></p>
<h3><code><a name="ca_clear_event">ca_clear_subscription()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -3167,8 +3170,8 @@ int ca_clear_subscription ( evid EVID );</pre>
<p>Cancel a subscription.</p>
<p>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 <code>ca_flush_io()</code>, <code>ca_pend_io()</code>,
<code>ca_pend_event()</code>, or <code>ca_sg_block()</code> are called. This allows several requests to be
efficiently sent together in one message.</p>
<h4>Arguments</h4>
@@ -3185,7 +3188,7 @@ efficiently sent together in one message.</p>
<h4>See Also</h4>
<p><a href="#ca_add_event">ca_create_subscription</a>()</p>
<p><code><a href="#ca_add_event">ca_create_subscription</a>()</code></p>
<h3><code><a name="ca_pend_io">ca_pend_io()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -3193,39 +3196,39 @@ int ca_pend_io ( double TIMEOUT );</pre>
<h4>Description</h4>
<p>This function flushes the send buffer and then blocks until outstanding <a
href="#ca_get">ca_get</a> requests complete, and until channels created
<p>This function flushes the send buffer and then blocks until outstanding
<code><a href="#ca_get">ca_get</a>()</code> requests complete, and until channels created
specifying null connection handler function pointers connect for the first
time.</p>
<ul>
<li>If ECA_NORMAL is returned then it can be safely assumed that all
outstanding <a href="#ca_get">ca_get</a> requests have completed
outstanding <code><a href="#ca_get">ca_get</a>()</code> requests have completed
successfully and channels created specifying null connection handler
function pointers have connected for the first time.</li>
<li>If ECA_TIMEOUT is returned then it must be assumed for all previous <a
href="#ca_get">ca_get</a> requests and properly qualified first time
<li>If ECA_TIMEOUT is returned then it must be assumed for all previous
<code><a href="#ca_get">ca_get</a>()</code> requests and properly qualified first time
channel connects have failed.</li>
</ul>
<p>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 <a href="#ca_get">ca_get</a> requests issued, and also any channels
subsequent call to <code>ca_pend_io()</code>. Specifically, the function will block only for
outstanding <code><a href="#ca_get">ca_get</a>()</code> 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 <a href="#ca_create_channel">ca_create_channel</a> requests generally
should not be reissued for the same process variable unless <a
href="#ca_clear_channel">ca_clear_channel</a> is called first.</p>
call to <code>ca_pend_io()</code> or ca client context creation whichever is later. Note
that <code><a href="#ca_create_channel">ca_create_channel</a>()</code> requests generally
should not be reissued for the same process variable unless
<code><a href="#ca_clear_channel">ca_clear_channel</a>()</code> is called first.</p>
<p>If no <a href="#ca_get">ca_get</a> or connection state change events are
outstanding then ca_pend_io() will flush the send buffer and return immediately
<p>If no <code><a href="#ca_get">ca_get</a>()</code> or connection state change events are
outstanding then <code>ca_pend_io()</code> will flush the send buffer and return immediately
<em>without processing any outstanding channel access background
activities</em>.</p>
<p>The delay specified to ca_pend_io() should take into account worst case
<p>The delay specified to <code>ca_pend_io()</code> 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.</p>
<p>Unlike <code><a href="#ca_pend_event">ca_pend_event</a></code>, this routine
<p>Unlike <code><a href="#ca_pend_event">ca_pend_event</a>()</code>, this routine
will not process CA's background activities if none of the selected IO requests
are pending.</p>
@@ -3247,11 +3250,11 @@ timeout</p>
<h4>See Also</h4>
<p><a href="#ca_get">ca_get</a>()</p>
<p><code><a href="#ca_get">ca_get</a>()</code></p>
<p><a href="#ca_create_channel">ca_create_channel</a>()</p>
<p><code><a href="#ca_create_channel">ca_create_channel</a>()</code></p>
<p><a href="#ca_test_io">ca_test_io</a>()</p>
<p><code><a href="#ca_test_io">ca_test_io</a>()</code></p>
<h3><code><a name="ca_test_io">ca_test_io()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -3259,11 +3262,11 @@ int ca_test_io();</pre>
<h4>Description</h4>
<p>This function tests to see if all <a href="#ca_get">ca_get</a> requests are
<p>This function tests to see if all <code><a href="#ca_get">ca_get</a>()</code> requests are
complete and channels created specifying a null connection callback function
pointer are connected. It will report the status of outstanding <a
href="#ca_get">ca_get</a> 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
<code><a href="#ca_get">ca_get</a>()</code> requests issued, and channels created specifying a
null connection callback function pointer, after the last call to <code>ca_pend_io()</code>
or CA context initialization whichever is later.</p>
<h4>Returns</h4>
@@ -3274,7 +3277,7 @@ or CA context initialization whichever is later.</p>
<h4>See Also</h4>
<p><a href="#ca_pend_io">ca_pend_io</a>()</p>
<p><code><a href="#ca_pend_io">ca_pend_io</a>()</code></p>
<h3><code><a name="ca_pend_event">ca_pend_event()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -3283,19 +3286,19 @@ int ca_poll ();</pre>
<h4>Description</h4>
<p>When ca_pend_event is invoked the send buffer is flushed and CA background
<p>When <code>ca_pend_event()</code> is invoked the send buffer is flushed and CA background
activity is processed for TIMEOUT seconds.</p>
<p>When ca_poll is invoked the send buffer is flushed and any outstanding CA
<p>When <code>ca_poll()</code> is invoked the send buffer is flushed and any outstanding CA
background activity is processed.</p>
<p>The ca_pend_event function will <em>not</em> return before the specified
<p>The <code>ca_pend_event()</code> function will <em>not</em> return before the specified
timeout expires and all unfinished channel access labor has been processed,
and unlike <code><a href="#ca_pend_io">ca_pend_io</a></code> returning from the
and unlike <code><a href="#ca_pend_io">ca_pend_io</a>()</code> returning from the
function does <em>not </em>indicate anything about the status of pending IO
requests.</p>
<p>Both <code>ca_pend_event</code> and <code>ca_poll</code> return ECA_TIMEOUT
<p>Both <code>ca_pend_event()</code> and <code>ca_poll()</code> return ECA_TIMEOUT
when successful. This behavior probably isn't intuitive, but it is preserved to
insure backwards compatibility.</p>
@@ -3346,7 +3349,7 @@ error code indicates an unsuccessful operation a stack dump is printed, if this
capability is available on the local operating system, and execution is
terminated.</p>
<p>SEVCHK is a macro envelope around ca_signal which only calls ca_signal() if
<p>SEVCHK is a macro envelope around <code>ca_signal()</code> which only calls <code>ca_signal()</code> 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.</p>
@@ -3506,10 +3509,10 @@ calling any other CA function, or once just after creating the CA context (if
you create the context explicitly). Use of this interface can improve latency
slightly in applications that use non preemptive callback mode at the expense
of some additional runtime overhead when compared to the alternative which is
just polling ca_pend_event periodically. It would probably not be appropriate
just polling <code>ca_pend_event()</code> 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
<code>ca_add_fd_registration</code> is called, a single pseudo UDP fd is
<code>ca_add_fd_registration()</code> 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 */];</pre>
<h4>Description</h4>
<p>The array dbr_value_size[TYPE] returns the size in bytes for the value
<p>The array <code>dbr_value_size[TYPE]</code> 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.</p>
@@ -3931,7 +3934,7 @@ SEVCHK ( status, .... );</pre>
<h4>See Also</h4>
<p><a href="#ca_add_event">ca_create_subscription</a>()</p>
<p><code><a href="#ca_add_event">ca_create_subscription</a>()</code></p>
<h3><code><a name="ca_sg_create">ca_sg_create()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -3943,10 +3946,10 @@ int ca_sg_create ( CA_SYNC_GID *PGID );</pre>
<p>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 <code>ca_sg_get()</code> and
<code>ca_sg_put()</code> respectively. The routines <code>ca_sg_block()</code> and <code>ca_sg_test()</code> 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
<code>ca_sg_reset()</code> is used to discard knowledge of old requests which have timed out
and in all likelihood will never be satisfied.</p>
<p>Any number of asynchronous groups can have application requested operations
@@ -3971,17 +3974,17 @@ SEVCHK ( status, Sync group create failed );</pre>
<h4>See Also</h4>
<p><a href="#ca_sg_delete">ca_sg_delete</a>()</p>
<p><code><a href="#ca_sg_delete">ca_sg_delete</a>()</code></p>
<p><a href="#ca_sg_block">ca_sg_block</a>()</p>
<p><code><a href="#ca_sg_block">ca_sg_block</a>()</code></p>
<p><a href="#ca_sg_test">ca_sg_test</a>()</p>
<p><code><a href="#ca_sg_test">ca_sg_test</a>()</code></p>
<p><a href="#ca_sg_reset">ca_sg_reset</a>()</p>
<p><code><a href="#ca_sg_reset">ca_sg_reset</a>()</code></p>
<p><a href="#ca_sg_put">ca_sg_array_put</a>()</p>
<p><code><a href="#ca_sg_put">ca_sg_array_put</a>()</code></p>
<p><a href="#ca_sg_get">ca_sg_array_get</a>()</p>
<p><code><a href="#ca_sg_get">ca_sg_array_get</a>()</code></p>
<h3><code><a name="ca_sg_delete">ca_sg_delete()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -4010,7 +4013,7 @@ SEVCHK ( status, Sync group delete failed );</pre>
<h4>See Also</h4>
<p><a href="#ca_sg_create">ca_sg_create</a>()</p>
<p><code><a href="#ca_sg_create">ca_sg_create</a>()</code></p>
<h3><code><a name="ca_sg_block">ca_sg_block()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -4020,17 +4023,17 @@ int ca_sg_block ( CA_SYNC_GID GID, double TIMEOUT );</pre>
<p>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 <code>ca_sg_array_get()</code> and calls to <code>ca_sg_array_put()</code>. 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 <code>ca_sg_block()</code>. This routine will only block
on outstanding queries issued after the last call to <code>ca_sg_block()</code>,
<code>ca_sg_reset()</code>, or <code>ca_sg_create()</code> whichever occurs later in time. If no queries
are outstanding then <code>ca_sg_block()</code> will return immediately without processing
any pending channel access activities.</p>
<p>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 <code>ca_sg_block()</code>. This routine will process pending channel
access background activity while it is waiting.</p>
<h4>Arguments</h4>
@@ -4059,9 +4062,9 @@ SEVCHK(status, Sync group block failed);</pre>
<h4>See Also</h4>
<p><a href="#ca_sg_test">ca_sg_test</a>()</p>
<p><code><a href="#ca_sg_test">ca_sg_test</a>()</code></p>
<p><a href="#ca_sg_reset">ca_sg_reset</a>()</p>
<p><code><a href="#ca_sg_reset">ca_sg_reset</a>()</code></p>
<h3><code><a name="ca_sg_test">ca_sg_test()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -4100,7 +4103,7 @@ int ca_sg_reset ( CA_SYNC_GID GID )</pre>
<h4>Description</h4>
<p>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 <code>ca_sg_test()</code> will return ECA_IODONE and <code>ca_sg_block()</code>
will not block unless additional subsequent requests are made.</p>
<h4>Arguments</h4>
@@ -4125,12 +4128,12 @@ int ca_sg_array_put ( CA_SYNC_GID GID, chtype TYPE,
unsigned long COUNT, chid CHID, void *PVALUE );</pre>
<p>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.</p>
outstanding request count of a synchronous group. The <code>ca_sg_array_put()</code>
functionality is implemented using <code>ca_array_put_callback()</code>.</p>
<p>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 <code>ca_flush_io()</code>, <code>ca_pend_io()</code>,
<code>ca_pend_event()</code>, or <code>ca_sg_block()</code> are called. This allows several requests to be
efficiently sent in one message.</p>
<p>If a connection is lost and then resumed outstanding puts are not
@@ -4179,7 +4182,7 @@ reissued.</p>
<h4>See Also</h4>
<p><a href="#ca_flush_io">ca_flush_io</a>()</p>
<p><code><a href="#ca_flush_io">ca_flush_io</a>()</code></p>
<h3><code><a name="ca_sg_get">ca_sg_array_get()</a></code></h3>
<pre>#include &lt;cadef.h&gt;
@@ -4190,16 +4193,16 @@ int ca_sg_array_get ( CA_SYNC_GID GID,
<h4>Description</h4>
<p>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.</p>
synchronous group. The <code>ca_sg_array_get()</code> functionality is implemented using
<code>ca_array_get_callback()</code>.</p>
<p>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.</p>
<p>The values written into your program's variables by <code>ca_sg_get()</code> should not be
referenced by your program until ECA_NORMAL has been received from <code>ca_sg_block()</code>,
or until <code>ca_sg_test()</code> returns ECA_IODONE.</p>
<p>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 <code>ca_flush_io()</code>, <code>ca_pend_io()</code>,
<code>ca_pend_event()</code>, or <code>ca_sg_block()</code> are called. This allows several requests to be
efficiently sent in one message.</p>
<p>If a connection is lost and then resumed outstanding gets are not
@@ -4247,11 +4250,11 @@ reissued.</p>
<h4>See Also</h4>
<p><a href="#ca_pend_io">ca_pend_io</a>()</p>
<p><code><a href="#ca_pend_io">ca_pend_io</a>()</code></p>
<p><a href="#ca_flush_io">ca_flush_io</a>()</p>
<p><code><a href="#ca_flush_io">ca_flush_io</a>()</code></p>
<p><a href="#ca_get">ca_get_callback</a>()</p>
<p><code><a href="#ca_get">ca_get_callback</a>()</code></p>
<h3><code><a name="ca_client_status">ca_client_status()</a></code></h3>
<pre>int ca_client_status ( unsigned level );
@@ -4262,7 +4265,7 @@ int ca_context_status ( struct ca_client_context *CONTEXT,
<p>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.</p>
<code>ca_client_status()</code> prints information about the calling threads CA context.</p>
<h4>Arguments</h4>
<dl>
@@ -4282,13 +4285,13 @@ returned.</p>
<h4>See Also</h4>
<p><a href="#ca_attach_context">ca_attach_context</a>()</p>
<p><code><a href="#ca_attach_context">ca_attach_context</a>()</code></p>
<p><a href="#ca_detach_context">ca_detach_context</a>()</p>
<p><code><a href="#ca_detach_context">ca_detach_context</a>()</code></p>
<p><a href="#ca_context_create">ca_context_create</a>()</p>
<p><code><a href="#ca_context_create">ca_context_create</a>()</code></p>
<p><a href="#ca_context_destroy">ca_context_destroy</a>()</p>
<p><code><a href="#ca_context_destroy">ca_context_destroy</a>()</code></p>
<h3><code><a name="ca_attach_context">ca_attach_context()</a></code></h3>
<pre>int ca_attach_context (struct ca_client_context *CONTEXT);</pre>
@@ -4297,7 +4300,7 @@ returned.</p>
<p>The calling thread becomes a member of the specified CA context. If
<code>ca_disable_preemptive_callback</code> is specified when
ca_context_create() is called (or if ca_task_initialize() is called) then
<code>ca_context_create()</code> is called (or if <code>ca_task_initialize()</code> is called) then
additional threads are <em>not </em>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.</p>
@@ -4318,13 +4321,13 @@ preemptively from more than one thread.</p>
<h4>See Also</h4>
<p><a href="#ca_current_context">ca_current_context</a>()</p>
<p><code><a href="#ca_current_context">ca_current_context</a>()</code></p>
<p><a href="#ca_detach_context">ca_detach_context</a>()</p>
<p><code><a href="#ca_detach_context">ca_detach_context</a>()</code></p>
<p><a href="#ca_context_create">ca_context_create</a>()</p>
<p><code><a href="#ca_context_create">ca_context_create</a>()</code></p>
<p><a href="#ca_context_destroy">ca_context_destroy</a>()</p>
<p><code><a href="#ca_context_destroy">ca_context_destroy</a>()</code></p>
<h3><code><a name="ca_detach_context">ca_detach_context()</a></code></h3>
<pre>void ca_detach_context();</pre>
@@ -4333,17 +4336,17 @@ preemptively from more than one thread.</p>
<p>Detach from any CA context currently attached to the calling thread. This
does <em>not</em> cleanup or shutdown any currently attached CA context (for
that use ca_context_destroy).</p>
that use <code>ca_context_destroy()</code>).</p>
<h4>See Also</h4>
<p><a href="#ca_current_context">ca_current_context</a>()</p>
<p><code><a href="#ca_current_context">ca_current_context</a>()</code></p>
<p><a href="#ca_attach_context">ca_attach_context</a>()</p>
<p><code><a href="#ca_attach_context">ca_attach_context</a>()</code></p>
<p><a href="#ca_context_create">ca_context_create</a>()</p>
<p><code><a href="#ca_context_create">ca_context_create</a>()</code></p>
<p><a href="#ca_context_destroy">ca_context_destroy</a>()</p>
<p><code><a href="#ca_context_destroy">ca_context_destroy</a>()</code></p>
<h3><code><a name="ca_dump_dbr">ca_dump_dbr()</a></code></h3>
<code><pre>void ca_dump_dbr (chtype TYPE, unsigned COUNT, const void * PDBR);</pre></code>