multiprocessing and accessing server's stdout

[Tim Arnold]

On May 28, 7:47 pm, "Martin P. Hellwig" <martin.hell... at dcuktec.org>
wrote:
> On 05/28/10 21:44, Adam Tauno Williams wrote:
>
> > On Fri, 2010-05-28 at 15:41 +0100, Martin P. Hellwig wrote:
> >> On 05/28/10 13:17, Adam Tauno Williams wrote:
> >> <cut>
> >>> You should be able to point it any any file-like object.  But, again,
> >>> why?
> >>> If you have the data in the process why send it tostdoutand redirect
> >>> it.  Why not just send the data to the client directly?
> >> Well you might want to multiplex it to more then one client, not saying
> >> that this is the case here, just something I imagine possible.
>
> > That still doesn't make sense.  Why 'multiplexstdout'?  Why not just
> > multiplex the data into proper IPC channels in the first place?
>
> I am going on a stretch here, I mostly agree with you, just trying to
> illustrate that there could be corner cases where this is sensible.
> The current situation could be that there is a client/server program
> (binary only perhaps) which is not multi-user safe.
>
> Python can be used as a wrapper around the server to make it
> multi-client, by emulating the exact behavior towards the client, the
> client program does not have to be changed.
>
> --
> mph

Hi, This is the setup I was asking about.
I've got users using a python-written command line client. They're
requesting services from a remote server that fires a LaTeX process. I
want them to see the stdout from the LaTeX process.

I was using multiprocessing to handle the requests, but the stdout
shows up on the server's terminal window where I started the
server.serve_forever process.

I started using RPyC and now the stdout appears on the client terminal
making the request.

I was trying to minimize the number of packages I use, hoping I could
get the same capability from multiprocessing that I get with RPyC.

thanks for the comments. I'm still processing what's been written
here.
--Tim