You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hc.apache.org by se...@apache.org on 2009/02/02 23:16:28 UTC

svn commit: r740126 - /httpcomponents/httpcore/trunk/src/docbkx/nio-ext.xml

Author: sebb
Date: Mon Feb  2 22:16:28 2009
New Revision: 740126

URL: http://svn.apache.org/viewvc?rev=740126&view=rev
Log:
Standardise on "thread-safe" rather than "thread safe"

Modified:
    httpcomponents/httpcore/trunk/src/docbkx/nio-ext.xml

Modified: httpcomponents/httpcore/trunk/src/docbkx/nio-ext.xml
URL: http://svn.apache.org/viewvc/httpcomponents/httpcore/trunk/src/docbkx/nio-ext.xml?rev=740126&r1=740125&r2=740126&view=diff
==============================================================================
--- httpcomponents/httpcore/trunk/src/docbkx/nio-ext.xml (original)
+++ httpcomponents/httpcore/trunk/src/docbkx/nio-ext.xml Mon Feb  2 22:16:28 2009
@@ -342,8 +342,8 @@
 IOSession iosession = sessionRequest.getSession();
 ]]></programlisting>
             <para>
-            <interfacename>SessionRequest</interfacename> implementations are expected to be thread 
-            safe. Session request can be aborted at any time by calling <methodname>
+            <interfacename>SessionRequest</interfacename> implementations are expected to be 
+            thread-safe. Session request can be aborted at any time by calling <methodname>
             IOSession#cancel()</methodname> from another thread of execution.
             </para>
             <programlisting><![CDATA[
@@ -495,7 +495,7 @@
         <para>
         Effectively non-blocking HTTP connections are wrappers around <interfacename>IOSession
         </interfacename> with HTTP specific functionality. Non-blocking HTTP connections are 
-        stateful and not thread safe. Input / output operations on non-blocking HTTP connections 
+        stateful and not thread-safe. Input / output operations on non-blocking HTTP connections 
         should be restricted to the dispatch events triggered by the I/O event dispatch thread. 
         </para>
         <section>
@@ -505,7 +505,7 @@
             therefore they need to maintain their own execution context. Each non-blocking HTTP 
             connection has an <interfacename>HttpContext</interfacename> instance associated with 
             it, which can be used to maintain a processing state. The <interfacename>HttpContext
-            </interfacename> instance is thread safe and can be manipulated from multiple threads.
+            </interfacename> instance is thread-safe and can be manipulated from multiple threads.
             </para>
             <programlisting><![CDATA[
 // Get non-blocking HTTP connection
@@ -600,14 +600,14 @@
             All non-blocking HTTP connections classes implement <interfacename>IOControl
             </interfacename> interface, which represents a subset of connection functionality for 
             controlling interest in I/O even notifications. <interfacename>IOControl
-            </interfacename> instances are expected to be fully thread safe. Therefore 
+            </interfacename> instances are expected to be fully thread-safe. Therefore 
             <interfacename>IOControl</interfacename> can be used to request / suspend I/O event 
             notifications from any thread. 
             </para>
             <para>
             One must take special precautions when interacting with non-blocking connections. 
             <interfacename>HttpRequest</interfacename> and <interfacename>HttpResponse
-            </interfacename>are not thread safe. It is generally advisable that all input / output 
+            </interfacename>are not thread-safe. It is generally advisable that all input / output 
             operations on a non-blocking connection are executed from the I/O event dispatch 
             thread.   
             </para>
@@ -1284,7 +1284,7 @@
 };
 ]]></programlisting>
                 <para>
-                Request handlers must be implemented in a thread safe manner. Similarly to 
+                Request handlers must be implemented in a thread-safe manner. Similarly to 
                 servlets, request handlers should not use instance variables unless access to those 
                 variables are synchronized.
                 </para>
@@ -1345,7 +1345,7 @@
 };
 ]]></programlisting>
                 <para>
-                Please note <interfacename>HttpResponse</interfacename> objects are not thread safe 
+                Please note <interfacename>HttpResponse</interfacename> objects are not thread-safe 
                 and may not be modified concurrently. Non-blocking request handlers must ensure 
                 the HTTP response cannot be accessed by more than one thread at a time.
                 </para>