This is an automated email from the ASF dual-hosted git repository.
jpeach pushed a commit to branch master
in repository https://git-dual.apache.org/repos/asf/trafficserver.git
The following commit(s) were added to refs/heads/master by this push:
new f9edce1 doc: Add more reference links to the IO guide.
f9edce1 is described below
commit f9edce13464700775a1f5245ab0f091a673d0faf
Author: James Peach <[email protected]>
AuthorDate: Thu Oct 6 20:32:50 2016 -0700
doc: Add more reference links to the IO guide.
---
doc/developer-guide/plugins/io/index.en.rst | 4 +--
doc/developer-guide/plugins/io/io-buffers.en.rst | 4 +--
.../plugins/io/net-vconnections.en.rst | 4 +--
.../plugins/io/transformations.en.rst | 34 +++++++++++-----------
4 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/doc/developer-guide/plugins/io/index.en.rst
b/doc/developer-guide/plugins/io/index.en.rst
index 427e7e5..184c78e 100644
--- a/doc/developer-guide/plugins/io/index.en.rst
+++ b/doc/developer-guide/plugins/io/index.en.rst
@@ -118,7 +118,7 @@ is obtained from ``input_vio`` by :c:func:`TSVIONBytesGet`.
When a vconnection calls back its user to indicate that it wants more
data (or when some other condition has occurred), it issues a call to
-``TSContCall``. It passes the ``TSVIO`` describing the operation as the
+:c:func:`TSContCall`. It passes the ``TSVIO`` describing the operation as the
data parameter, and one of the values below as the event parameter.
``TS_EVENT_ERROR``
@@ -164,7 +164,7 @@ For example: the null transform plugin's transformation
receives
events from the downstream vconnection as a result of the call to
:c:func:`TSVConnWrite`.
-After using a vconnection, the user must call ``TSVConnClose`` or
+After using a vconnection, the user must call :c:func:`TSVConnClose` or
:c:func:`TSVConnAbort`. While both calls indicate that the vconnection can
destroy itself, :c:func:`TSVConnAbort` should be used when the connection is
being closed abnormally. After a call to :c:func:`TSVConnClose` or
diff --git a/doc/developer-guide/plugins/io/io-buffers.en.rst
b/doc/developer-guide/plugins/io/io-buffers.en.rst
index d7d199d..73c49ac 100644
--- a/doc/developer-guide/plugins/io/io-buffers.en.rst
+++ b/doc/developer-guide/plugins/io/io-buffers.en.rst
@@ -28,7 +28,7 @@ buffer blocks that point to buffer data. Both the buffer block
(``TSIOBufferBlock``) and buffer data (``TSIOBufferData``) data
structures are reference-counted, so they can reside in multiple buffers
at the same time. This makes it extremely efficient to copy data from
-one IO buffer to another via ``TSIOBufferCopy``, since Traffic Server
+one IO buffer to another via :c:func:`TSIOBufferCopy`, since Traffic Server
must only copy pointers and adjust reference counts appropriately (and
doesn't actually copy any data).
@@ -51,6 +51,6 @@ Additional information about IO buffer functions:
- Bytes that have already been read may not necessarily be freed within
the ``TSIOBuffer``. To consume bytes that have been read, you must
- call ``TSIOBufferConsume``.
+ call :c:func:`TSIOBufferConsume`.
diff --git a/doc/developer-guide/plugins/io/net-vconnections.en.rst
b/doc/developer-guide/plugins/io/net-vconnections.en.rst
index 744c960..07a6d4e 100644
--- a/doc/developer-guide/plugins/io/net-vconnections.en.rst
+++ b/doc/developer-guide/plugins/io/net-vconnections.en.rst
@@ -30,6 +30,6 @@ the Traffic Server abstraction for doing asynchronous IO.
The netvconnection functions are listed below:
-- [dox 'TSNetAccept'] in [dox "TSNetAccept" :src\_file]
-- [dox %TSNetConnect%] in [dox :src\_file]
+- :c:func:`TSNetAccept`
+- :c:func:`TSNetConnect`
diff --git a/doc/developer-guide/plugins/io/transformations.en.rst
b/doc/developer-guide/plugins/io/transformations.en.rst
index 947e6f3..baa613e 100644
--- a/doc/developer-guide/plugins/io/transformations.en.rst
+++ b/doc/developer-guide/plugins/io/transformations.en.rst
@@ -30,10 +30,10 @@ VConnections (net VConnections and cache VConnections) are
implemented
in iocore. As mentioned earlier, a given vconnection can have a maximum
of one read operation and one write operation being performed on it. The
vconnection user gets information about the operation being performed by
-examining the VIO returned by a call to ``TSVConnRead`` or
-``TSVConnWrite``. The implementor, in turn, gets a handle on the VIO
-operation by examining the VIO returned by ``TSVConnReadVIOGet`` or
-``TSVConnWriteVIOGet`` (recall that every vconnection created through
+examining the VIO returned by a call to :c:func:`TSVConnRead` or
+:c:func:`TSVConnWrite`. The implementor, in turn, gets a handle on the VIO
+operation by examining the VIO returned by :c:func:`TSVConnReadVIOGet` or
+:c:func:`TSVConnWriteVIOGet` (recall that every vconnection created through
the Traffic Server API has an associated read VIO and write VIO, even if
it only supports reading or writing).
@@ -73,19 +73,19 @@ similar. Their basic form looks something like the code
fragment below:
This code fragment basically shows that many vconnections simply want to
destroy themselves when they are closed. However, the situation might
also require the vconnection to do some cleanup processing - which is
-why ``TSVConnClose`` does not simply just destroy the vconnection.
+why :c:func:`TSVConnClose` does not simply just destroy the vconnection.
Vconnections are state machines that are animated by the events they
receive. An event is sent to the vconnection whenever an
-``TSVConnRead``, ``TSVConnWrite``, ``TSVConnClose``,
-``TSVConnShutdown``, or ``TSVIOReenable`` call is performed.
-``TSVIOReenable`` indirectly references the vconnection through a
+:c:func:`TSVConnRead`, :c:func:`TSVConnWrite`, :c:func:`TSVConnClose`,
+:c:func:`TSVConnShutdown`, or :c:func:`TSVIOReenable` call is performed.
+:c:func:`TSVIOReenable` indirectly references the vconnection through a
back-pointer in the VIO structure to the vconnection. The vconnection
itself only knows which call was performed by examining its state and
-the state of its VIOs. For example, when ``TSVConnClose`` is called, the
+the state of its VIOs. For example, when :c:func:`TSVConnClose` is called, the
vconnection is sent an immediate event (``TS_EVENT_IMMEDIATE``). For
every event the vconnection receives, it needs to check its closed flag
-to see if it has been closed. Similarly, when ``TSVIOReenable`` is
+to see if it has been closed. Similarly, when :c:func:`TSVIOReenable` is
called, the vconnection is sent an immediate event. For every event the
vconnection receives, it must check its VIOs to see if the buffers have
been modified to a state in which it can continue processing one of its
@@ -159,10 +159,10 @@ Here's how to make sure that all incoming data is
consumed:
``TSVIONTodoGet`` (``input_vio``). This value should go to zero when
all of the upstream data is consumed
(``TSVIONTodoGet = nbytes - ndone``). Do not send
- ``TS_EVENT_VCONN_WRITE_COMPLETE`` events if ``TSVIONTodoGet`` is
+ ``TS_EVENT_VCONN_WRITE_COMPLETE`` events if :c:func:`TSVIONTodoGet` is
greater than zero.
- The transformation passes data out of itself by using the output
- vconnection retrieved by ``TSTransformOutputVConnGet``. Immediately
+ vconnection retrieved by :c:func:`TSTransformOutputVConnGet`. Immediately
before Traffic Server initiates the write operation (which inputs
data into the transformation), it sets the output vconnection either
to the next transformation in the chain of transformations or to a
@@ -172,12 +172,12 @@ Here's how to make sure that all incoming data is
consumed:
be deallocated.
- All of the transformations in a transformation chain share the
transaction's mutex. This small restriction (enforced by
- ``TSTransformCreate``) removes many of the locking complications of
+ :c:func:`TSTransformCreate`) removes many of the locking complications of
implementing general vconnections. For example, a transformation does
not have to grab its write VIO mutex before accessing its write VIO
because it knows it already holds the mutex.
-The transformation functions are: \*
-:c:func:`TSTransformCreate`
-\*
-:c:func:`TSTransformOutputVConnGet`
+The transformation functions are:
+
+ - :c:func:`TSTransformCreate`
+ - :c:func:`TSTransformOutputVConnGet`
--
To stop receiving notification emails like this one, please contact
['"[email protected]" <[email protected]>'].
