[py-dev] execnet: redirecting stdout and stderr from remote threads

[holger krekel]

On Fri, Jul 10, 2009 at 12:53 +0200, holger krekel wrote:
> On Fri, Jul 10, 2009 at 20:21 +1000, Gordon Wrigley wrote:
> > >> I have execnet's stdout and stderr redirecting working and it does a
> > >> fine job for the initial thread, but I'm also creating a bunch of
> > >> helper threads on the remote end of the connection and I can't figure
> > >> out how to get the stdout and stderr for them redirected.
> > 
> > > stdout redirection is thread-aware.  This is because
> > > when calling
> > >
> > >    gateway.remote_init_threads(num=3)
> > >
> > > you would have three execution threads on the remote
> > > side and stdout redirection would separate the three
> > > execution's stdout redirections.   Can you use
> > > maybe make use of this threading handling?  If not
> > > then maybe we can think of introducing a way
> > > to configure the exact behaviour but it would complicate
> > > the API a bit which i'd like to avoid.
> > 
> > I need to create the threads at the remote end and on demand so I
> > don't think I'm going to be able to use execnets threading support.
> > My usage pattern is rather bizarre, maybe a better way to approach
> > this would be to build my own stdout / stderr redirection on top of
> > execnet sockets.
> 
> yes, might make sense then.  I attached a working example
> how to do general output redirection, maybe that helps you. 

now attached for real - let me know if there are problems with it.

holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: redirect_remote_output.py
Type: text/x-python
Size: 660 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20090710/a257fb1a/attachment.py>