Re: Re: Re: Re: capture output of a daemon in a tk widget on win32

I agree with JamesNC on this one, while it should be possible to fork after MainLoop and use CORE::exit, in reality it doesn't work reliably (or at all in most cases). Ditto for many other things on win32, especially related to IPC, blocking, filehandles, shared memory, etc... This question (along with my last 50 or so...) relates to a project that i started a couple of months ago, developing a medium sized Tk app involving about 6-7 different processes client-side and a handful of networking. Needless to say, i've run into many bugs along the way, and agree it's frustrating when things dont behave as documented or expected.

Back to the question.

In response to your program, it doesn't really address my problem. You're simply forking another process, using pipes to communicate, and polling each end while you wait for something to do. Keeps MainLoop running while you do stuff, sure, (been there, achieved that) but my question was more than that. So, no bucket just yet! :)

I've just simplified it by removing the requirement of stderr for the time being. This leaves two remaining issues: non-blocking read, and MainLoop. Solve the first, and the second shouldn't be an issue!

My output is now (varies):

read_stdout()
sysread() got 9 bytes:
[stdout1

]
read_stdout()
sysread() got 9 bytes:
[stdout2

]
[download]

<pause for 10 seconds>

read_stdout()
sysread() got 9 bytes:
[stdout3

]
read_stdout()
sysread() got 9 bytes:
[stdout4

]
read_stdout()
sysread() got 0 bytes:
[]
[download]

- ><iper

use japh; print;
[download]

Comment on Re: Re: Re: Re: capture output of a daemon in a tk widget on win32 Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: capture output of a daemon in a tk widget on win32 by JamesNC (Chaplain) on Mar 25, 2004 at 01:53 UTC
I would use POE then... :0)	[reply]