Add a WARNING pragma
[ghc-hetmet.git] / docs / users_guide / using.xml
index ef62d59..4b3024a 100644 (file)
@@ -841,11 +841,13 @@ ghc -c Foo.hs</screen>
     of warnings which are generally likely to indicate bugs in your
     program.  These are:
     <option>-fwarn-overlapping-patterns</option>,
-    <option>-fwarn-deprecations</option>,
+    <option>-fwarn-warnings-deprecations</option>,
     <option>-fwarn-deprecated-flags</option>,
     <option>-fwarn-duplicate-exports</option>,
-    <option>-fwarn-missing-fields</option>, and
-    <option>-fwarn-missing-methods</option>.  The following flags are
+    <option>-fwarn-missing-fields</option>,
+    <option>-fwarn-missing-methods</option>, and
+    <option>-fwarn-dodgy-foreign-imports</option>.  The following
+    flags are
     simple ways to select standard &ldquo;packages&rdquo; of warnings:
     </para>
 
@@ -917,15 +919,16 @@ ghc -c Foo.hs</screen>
     <variablelist>
 
       <varlistentry>
-       <term><option>-fwarn-deprecations</option>:</term>
+       <term><option>-fwarn-warnings-deprecations</option>:</term>
        <listitem>
-         <indexterm><primary><option>-fwarn-deprecations</option></primary>
+         <indexterm><primary><option>-fwarn-warnings-deprecations</option></primary>
          </indexterm>
+         <indexterm><primary>warnings</primary></indexterm>
          <indexterm><primary>deprecations</primary></indexterm>
-         <para>Causes a warning to be emitted when a deprecated
-         function or type is used.  Entities can be marked as
-         deprecated using a pragma, see <xref
-         linkend="deprecated-pragma"/>.</para>
+         <para>Causes a warning to be emitted when a
+         module, function or type with a WARNING or DEPRECATED pragma
+      is used. See <xref linkend="warning-deprecated-pragma"/> for more
+      details on the pragmas.</para>
 
          <para>This option is on by default.</para>
        </listitem>
@@ -945,6 +948,30 @@ ghc -c Foo.hs</screen>
       </varlistentry>
 
       <varlistentry>
+       <term><option>-fwarn-dodgy-foreign-imports</option>:</term>
+       <listitem>
+         <indexterm><primary><option>-fwarn-dodgy-foreign-imports</option></primary>
+         </indexterm>
+         <para>Causes a warning to be emitted for foreign imports of
+         the following form:</para>
+<programlisting>
+foreign import "f" f :: FunPtr t
+</programlisting>
+          <para>on the grounds that it probably should be</para>
+<programlisting>
+foreign import "&amp;f" f :: FunPtr t
+</programlisting>
+          <para>The first form declares that `f` is a (pure) C
+          function that takes no arguments and returns a pointer to a
+          C function with type `t`, whereas the second form declares
+          that `f` itself is a C function with type `t`.  The first
+          declaration is usually a mistake, and one that is hard to
+          debug because it results in a crash, hence this
+          warning.</para>
+       </listitem>
+      </varlistentry>
+
+      <varlistentry>
        <term><option>-fwarn-dodgy-imports</option>:</term>
        <listitem>
          <indexterm><primary><option>-fwarn-dodgy-imports</option></primary>
@@ -1738,7 +1765,7 @@ f "2"    = 2
     parallelism.</para>
     
     <sect2 id="parallel-options">
-      <title>Options to enable SMP parallelism</title>
+      <title>Options for SMP parallelism</title>
 
       <para>In order to make use of multiple CPUs, your program must be
        linked with the <option>-threaded</option> option (see <xref
@@ -1752,25 +1779,66 @@ f "2"    = 2
            <para><indexterm><primary><option>-N<replaceable>x</replaceable></option></primary><secondary>RTS option</secondary></indexterm>
              Use <replaceable>x</replaceable> simultaneous threads when
              running the program.  Normally <replaceable>x</replaceable>
-             should be chosen to match the number of CPU cores on the machine.
-             There is no means (currently) by which this value may vary after
-             the program has started.</para> 
-           
-           <para>For example, on a dual-core machine we would probably use
+             should be chosen to match the number of CPU cores on the
+             machine<footnote><para>Whether hyperthreading cores should be counted or not is an
+             open question; please feel free to experiment and let us know what
+                 results you find.</para></footnote>.  For example,
+             on a dual-core machine we would probably use
              <literal>+RTS -N2 -RTS</literal>.</para>
            
-           <para>Whether hyperthreading cores should be counted or not is an
-             open question; please feel free to experiment and let us know what
-             results you find.</para>
+            <para>Setting <option>-N</option> also has the effect of
+             setting <option>-g</option> (the number of OS threads to
+             use for garbage collection) to the same value.</para>
+
+            <para>There is no means (currently) by which this value
+             may vary after the program has started.</para>
          </listitem>
        </varlistentry>
       </variablelist>
+
+      <para>The following options affect the way the runtime schedules
+      threads on CPUs:</para>
+
+      <variablelist>
+       <varlistentry>
+         <term><option>-qm</option></term>
+          <indexterm><primary><option>-qm</option></primary><secondary>RTS
+          option</secondary></indexterm>
+         <listitem>
+            <para>Disable automatic migration for load balancing.
+            Normally the runtime will automatically try to schedule
+            threads across the available CPUs to make use of idle
+            CPUs; this option disables that behaviour.  It is probably
+            only of use if you are explicitly scheduling threads onto
+            CPUs with <literal>GHC.Conc.forkOnIO</literal>.</para>
+          </listitem>
+        </varlistentry>
+       <varlistentry>
+         <term><option>-qw</option></term>
+          <indexterm><primary><option>-qw</option></primary><secondary>RTS
+          option</secondary></indexterm>
+         <listitem>
+            <para>Migrate a thread to the current CPU when it is woken
+            up.  Normally when a thread is woken up after being
+            blocked it will be scheduled on the CPU it was running on
+            last; this option allows the thread to immediately migrate
+            to the CPU that unblocked it.</para> 
+            <para>The rationale for allowing this eager migration is
+            that it tends to move threads that are communicating with
+            each other onto the same CPU; however there are
+            pathalogical situations where it turns out to be a poor
+            strategy.  Depending on the communication pattern in your
+            program, it may or may not be a good idea.</para>
+          </listitem>
+        </varlistentry>
+       </variablelist>
     </sect2>
       
     <sect2>
       <title>Hints for using SMP parallelism</title>
 
-      <para>Add the <literal>-sstderr</literal> RTS option when
+      <para>Add the <literal>-s</literal> RTS option when
        running the program to see timing stats, which will help to tell you
        whether your program got faster by using more CPUs or not.  If the user
        time is greater than