btw, that whole sending a channel over a channel thing is beautiful and has proved very helpful
G On Fri, Jul 10, 2009 at 9:05 PM, holger krekel<hol...@merlinux.eu> wrote: > 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 > _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
