--- a/xml/en/docs/nginx_dtrace_pid_provider.xml	Thu Oct 04 15:02:55 2012 +0000
+++ b/xml/en/docs/nginx_dtrace_pid_provider.xml	Fri Oct 05 04:15:57 2012 +0000
@@ -20,15 +20,15 @@
 </para>
 
 <para>
-Although nginx build with <link doc="debugging_log.xml">--with-debug</link>
+Although nginx built with the <link doc="debugging_log.xml">--with-debug</link>
 option already provides a lot of information about request processing,
 it is sometimes desirable to trace particular parts of code path more
-thoroughly and at the same time omit the rest of debug output.
+thoroughly and at the same time omit the rest of debugging output.
 DTrace pid provider (available on Solaris, OS X) is a useful tool to
-explore userland programs internals, since it doesn’t require any code
+explore userland program’s internals, since it doesn’t require any code
 changes and it can help with the task.
-E.g. a simple DTrace script to trace and print nginx functions calls
-may look like:
+A simple DTrace script to trace and print nginx function calls
+may look like this:
 
 <programlisting>
 #pragma D option flowindent
@@ -53,14 +53,13 @@
 
 <para>
 One of the common scenarios for using DTrace with nginx is the following:
-attach to the nginx worker to log request lines and request start times.
+attach to the nginx worker process to log request lines and request start times.
 The corresponding function to attach is
-<literal>ngx_http_process_request</literal>, and the argument in question
-is a pointer to <literal>ngx_http_request_t</literal> structure.
+<c-func>ngx_http_process_request</c-func>, and the argument in question
+is a pointer to the <literal>ngx_http_request_t</literal> structure.
 DTrace script for such request logging can be as simple as:
 
 <programlisting>
-
 pid$target::*ngx_http_process_request:entry
 {
     this->request = (ngx_http_request_t *)copyin(arg0, sizeof(ngx_http_request_t));
@@ -69,19 +68,20 @@
     printf("request line = %s\n", this->request_line);
     printf("request start sec = %d\n", this->request->start_sec);
 }
+</programlisting>
 
-</programlisting>
 </para>
 
 <para>
 It should be noted that in the example above DTrace requires some knowledge
-about <literal>ngx_http_process_request</literal> structure.
+about the <literal>ngx_http_process_request</literal> structure.
 Unfortunately while it is possible to use a specific <literal>#include</literal>
 directive in the DTrace script and then pass it to a C preprocessor
-(with -C flag), that doesn’t really work.
-Due to a lot of cross dependencies almost all nginx header files
+(with the <literal>-C</literal> flag), that doesn’t really work.
+Due to a lot of cross dependencies, almost all nginx header files
 have to be included.
-In turn, based on configure script settings, nginx headers will include PCRE,
+In turn, based on <command>configure</command> script settings,
+nginx headers will include PCRE,
 OpenSSL and a variety of system header files.
 While in theory all those header files related to a specific nginx build
 might be included in DTrace script preprocessing and compilation, in reality
@@ -91,7 +91,7 @@
 
 <para>
 The problem above can be solved by including only the relevant and
-necessary structures and types definitions in the DTrace script.
+necessary structure and type definitions in the DTrace script.
 DTrace has to know sizes of structures, types, and fields offsets.
 Thus dependencies can be further reduced by manually optimizing
 structure definitions for use with DTrace.
@@ -105,17 +105,17 @@
 <para>
 First of all <literal>objs/ngx_auto_config.h</literal> file generated by
 configure should be included, because it defines a number of constants
-affecting various <literal>#ifdef’s</literal>.
-After that there’s some basic types and definitions
+affecting various <literal>#ifdef</literal>’s.
+After that, some basic types and definitions
 like <literal>ngx_str_t</literal>, <literal>ngx_table_elt_t</literal>,
-<literal>ngx_uint_t</literal> etc. should be put at the beginning of
+<literal>ngx_uint_t</literal> etc. should be put at the beginning of the
 DTrace script.
 These definitions are compact, commonly used and unlikely to be
 frequently changed.
 </para>
 
 <para>
-Then there’s the <literal>ngx_http_process_request_t</literal> structure which
+Then there’s the <literal>ngx_http_process_request_t</literal> structure that
 contains a lot of pointers to other structures.
 Because these pointers are really irrelevant to this script, and because they
 have the same size, it is possible to just replace them with void pointers.
@@ -127,19 +127,19 @@
 typedef ngx_http_request_body_t void;
 </programlisting>
 
-Last but not least it is necessary to add definitions of two member structures:
-<literal>ngx_http_headers_in_t</literal> and
-<literal>ngx_http_headers_out_t</literal>, callback functions
-declarations and constants definitions.
+Last but not least it is necessary to add definitions of two member structures
+(<literal>ngx_http_headers_in_t</literal>,
+<literal>ngx_http_headers_out_t</literal>),
+declarations of callback functions and definitions of constants.
 </para>
 
 <para>
-Final DTrace script can be downloaded
+The final DTrace script can be downloaded from
 <link url="http://nginx.org/download/trace_process_request.d">here</link>.
 </para>
 
 <para>
-The example below shows the output of the DTrace script:
+The following example shows the output of running this script:
 
 <programlisting>
 # dtrace -C -I ./objs -s trace_process_request.d -p 4848
@@ -155,7 +155,7 @@
 </para>
 
 <para>Using similar techniques the reader should be able to trace other
-nginx functions calls.
+nginx function calls.
 </para>
 
 </section>