Documentation fixes. Closes #151

doc/ChangeLog

@@ -1,3 +1,8
[phone]  Fernando Perez  <[e-mail]>
+
+	* ipython.1: update man page and full manual with information
+	about threads (remove outdated warning).  Closes #151.
+
 2007-05-09  Fernando Perez  <[e-mail]>
 
 	* IPython/Extensions/ipy_constants.py: Add Gael's constants module

doc/ipython.1

@@ -88,21 +88,6 There is unfortunately no way for IPython to determine at runtime whether \-tk
 will work reliably or not, so you will need to do some experiments before
 relying on it for regular work.
 .
-.SS A WARNING ABOUT SIGNALS AND THREADS
-When any of the thread systems (GTK, QT or WX) are active, either directly or
-via \-pylab with a threaded backend, it is impossible to interrupt
-long-running Python code via Ctrl\-C.  IPython can not pass the
-KeyboardInterrupt exception (or the underlying SIGINT) across threads, so any
-long-running process started from IPython will run to completion, or will have
-to be killed via an external (OS-based) mechanism.
-.br
-.sp 1
-To the best of my knowledge, this limitation is imposed by the Python
-interpreter itself, and it comes from the difficulty of writing portable
-signal/threaded code.  If any user is an expert on this topic and can suggest
-a better solution, I would love to hear about it.  In the IPython sources,
-look at the Shell.py module, and in particular at the runcode() method.
-.
 .SH REGULAR OPTIONS
 After the above threading options have been given, regular options can follow
 in any order.  All options can be abbreviated to their shortest non-ambiguous

doc/manual_base.lyx

@@ -8773,6 +8773,10 IPython, via the
 \family typewriter
 -qthread
 \family default
+, 
+\family typewriter
+-q4thread
+\family default
  and 
 \family typewriter
 -wthread
@@ -8783,11 +8787,11 IPython, via the
 
 \end_inset
 
-), can run in multithreaded mode to support pyGTK, Qt and WXPython applications
- respectively.
+), can run in multithreaded mode to support pyGTK, Qt3, Qt4 and WXPython
+ applications respectively.
  These GUI toolkits need to control the python main loop of execution, so
- under a normal Python interpreter, starting a pyGTK, Qt or WXPython application
- will immediately freeze the shell.
+ under a normal Python interpreter, starting a pyGTK, Qt3, Qt4 or WXPython
+ application will immediately freeze the shell.
  
 \end_layout
 
@@ -8835,50 +8839,6 As indicated in Sec.\InsetSpace ~
 \end_layout
 
 \begin_layout Subsection
-Signals and Threads
-\end_layout
-
-\begin_layout Standard
-When any of the thread systems (GTK, Qt or WX) are active, either directly
- or via 
-\family typewriter
--pylab
-\family default
- with a threaded backend, it is impossible to interrupt long-running Python
- code via 
-\family typewriter
-Ctrl-C
-\family default
-.
- IPython can not pass the KeyboardInterrupt exception (or the underlying
- 
-\family typewriter
-SIGINT
-\family default
-) across threads, so any long-running process started from IPython will
- run to completion, or will have to be killed via an external (OS-based)
- mechanism.
-\end_layout
-
-\begin_layout Standard
-To the best of my knowledge, this limitation is imposed by the Python interprete
-r itself, and it comes from the difficulty of writing portable signal/threaded
- code.
- If any user is an expert on this topic and can suggest a better solution,
- I would love to hear about it.
- In the IPython sources, look at the 
-\family typewriter
-Shell.py
-\family default
- module, and in particular at the 
-\family typewriter
-runcode()
-\family default
- method.
- 
-\end_layout
-
-\begin_layout Subsection
 I/O pitfalls
 \end_layout