multiprocessing and accessing server's stdout
in [Python]
|
Prev: TypeError: _new_() takes exactly 3 arguments (2 given) - whatdoes it mean?
Next: TypeError: _new_() takes exactly 3 arguments (2 given) - what does it mean?
From: Tim Arnold on 26 May 2010 14:47 Hi, I'm using multiprocessing's BaseManager to create a server on one machine and a client on another. The client fires a request and the server does some work, the result of which ends up on a shared file system that both the client and server can see. However, I need the client machine to see the stdout of the process running on the server. Not sure this is doable--I've been unable to google anything useful on this one. thanks, --Tim Arnold
From: Adam Tauno Williams on 26 May 2010 16:52 On Wed, 2010-05-26 at 11:47 -0700, Tim Arnold wrote: > Hi, > I'm using multiprocessing's BaseManager to create a server on one > machine and a client on another. The client fires a request and the > server does some work, the result of which ends up on a shared file > system that both the client and server can see. > However, I need the client machine to see the stdout of the process > running on the server. Not sure this is doable--I've been unable to > google anything useful on this one. Nope, it isn't. Don't use stdout, use an IPC mechanism to communicate between the client and the server if you need feedback. -- Adam Tauno Williams <awilliam(a)whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
From: Tim Arnold on 27 May 2010 11:36 On May 26, 4:52 pm, Adam Tauno Williams <awill...(a)whitemice.org> wrote: > On Wed, 2010-05-26 at 11:47 -0700, Tim Arnold wrote: > > Hi, > > I'm using multiprocessing's BaseManager to create a server on one > > machine and a client on another. The client fires a request and the > > server does some work, the result of which ends up on a shared file > > system that both the client and server can see. > > However, I need the client machine to see the stdout of the process > > running on the server. Not sure this is doable--I've been unable to > > google anything useful on this one. > > Nope, it isn't. Don't use stdout, use an IPC mechanism to communicate > between the client and the server if you need feedback. > -- > Adam Tauno Williams <awill...(a)whitemice.org> LPIC-1, Novell CLA > <http://www.whitemiceconsulting.com> > OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba Thanks for that info, it saves me some time. This is a new area for me though: do you redirect stdout on the server to a socket and have the client listen and somehow pipe the sockets contents to the client stdout? Interestingly, the RPYc package manages it--that is, the client gets the stdout of the server process, so I'll dig into that code to get an idea. In the meantime, are there any recipes or other docs that would be helpful? I've been googling but without much luck. thanks, --Tim
From: Adam Tauno Williams on 28 May 2010 08:17 On Thu, 2010-05-27 at 08:36 -0700, Tim Arnold wrote: > On May 26, 4:52 pm, Adam Tauno Williams <awill...(a)whitemice.org> > wrote: > > On Wed, 2010-05-26 at 11:47 -0700, Tim Arnold wrote: > > > Hi, > > > I'm using multiprocessing's BaseManager to create a server on one > > > machine and a client on another. The client fires a request and the > > > server does some work, the result of which ends up on a shared file > > > system that both the client and server can see. > > > However, I need the client machine to see the stdout of the process > > > running on the server. Not sure this is doable--I've been unable to > > > google anything useful on this one. > > > > Nope, it isn't. Don't use stdout, use an IPC mechanism to communicate > > between the client and the server if you need feedback. > Thanks for that info, it saves me some time. This is a new area for me > though: do you redirect stdout on the server to a socket and have the > client listen and somehow pipe the sockets contents to the client > stdout? No, I close stdin, stderr, and stdout on the server processes and attach them to /dev/null. Just don't use stdout. > Interestingly, the RPYc package manages it--that is, the client gets > the stdout of the server process, so I'll dig into that code to get an > idea. In the meantime, are there any recipes or other docs that would > be helpful? I've been googling but without much luck. Closing stdout and attaching it to any other file descriptor is pretty simple. sys.stdout = open('/dev/null', 'w') 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 to stdout and redirect it. Why not just send the data to the client directly? -- Adam Tauno Williams <awilliam(a)whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
From: Martin P. Hellwig on 28 May 2010 10:41
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 to stdout and 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. -- mph |