Re: [matplotlib-devel] Another try at interactive gui thread

[Steve C. <ste...@ya...>]

On Thu, 2005-01-27 at 17:14 -0700, Fernando Perez wrote: 
> > - runsource() and runcode() are synchronised using wait()/notify() so
> > they deal with one code object at a time. If self.code_to_run is changed
> > to a code queue (using list.append() and list.pop(0)) then the wait
> > ()/notify() could be removed and the interpreter thread would return
> > immediately it adds the code to self.code_to_run and not when the main
> > thread has executed the code.
> 
> On second thought, I don't think this is a good idea in general.  The problem 
> I see is the serialization of output.  Imagine you start a long running job 
> and you get the prompt back right away.  If your job prints to stdout along 
> the way (as is very common with scientific codes), your input line will get 
> clobbered by this output.
> 
> If you could run in a gui window where you could associate the stdout for each 
> input 'cell' with its own output one, it would be different.  This is exactly 
> how Mathematica notebooks work, they stack a queue of cells for running 
> sequentially, you get your typing prompt back immediately, but the output of 
> each command is collected in an Out[] cell next to the corresponding In[] one. 
>   In a plain terminal, I don't see how we can make this work (in fact, in a 
> terminal Mathematica also serializes output for this very reason).
> 
> I have been toying with the idea of adding a way to 'background' processes 
> automatically to ipython, by creating a list of worker threads for long 
> running jobs.  But the problem of handling stdout has me stumped.
> 
> I'm open to comments, though, or perhaps I'm missing something obvious here.

So removing wait()/notify() would not be such a good idea, it might be
useful if you are only running gui code, but not when the command prints
to stdout.

To run a background process as a thread you would need to redirect its
stdout somewhere (StringIO for example). The problem with using threads
for this is that they share the stdout with the main thread, so if you
redirect the background threads stdout you will redirect the python
interpreters stdout too!
You could run a background process as an actual process and not a thread
(and Python 2.4 has a new subprocess module which unifies the previous
solutions of os.system, os.spawn*, os.popen*, popen2.*, commands.*). It
lets you redirect stdout, but is used for running executables, not
calling python functions.

It has me stumped too, how can you call a python function and redirect
its stdout independent of the python interpreters stdout?

Steve