From 1f47d1a9d65dfd808bae5ca424ddd7ea613ecd89 2007-05-10 06:20:19 From: fperez Date: 2007-05-10 06:20:19 Subject: [PATCH] Documentation fixes. Closes #151 --- diff --git a/doc/ChangeLog b/doc/ChangeLog index f774649..79b8498 100644 --- a/doc/ChangeLog +++ b/doc/ChangeLog @@ -1,3 +1,8 @@ +2007-05-10 Fernando Perez + + * ipython.1: update man page and full manual with information + about threads (remove outdated warning). Closes #151. + 2007-05-09 Fernando Perez * IPython/Extensions/ipy_constants.py: Add Gael's constants module diff --git a/doc/ipython.1 b/doc/ipython.1 index e63a11b..be9ce42 100644 --- a/doc/ipython.1 +++ b/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 diff --git a/doc/manual_base.lyx b/doc/manual_base.lyx index 750518a..e1174b5 100644 --- a/doc/manual_base.lyx +++ b/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