Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

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

by JamesNC (Chaplain)
on Mar 24, 2004 at 20:47 UTC ( [id://339543]=note: print w/replies, xml ) Need Help??


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

Why would I make this up? Forking after MainLoop on Win32 doesn't work. The latest version of Tk on Win that is not beta is 800.024, I have tried beta 10 (804.XX) and it dies there too on Win32(2K and XP)... and that is why I said that. Believe me I have tried. Win32 doesn't really fork. It creates a thread I am told. Hence it's odd behavior ( FRUSTRATING BEHAVIOR ) in some modules. I didn't just make it up, and that is why the gent asked the question because it (and fileEvent and lots of other Tk behaviors should work but don't. I would not try to tell stuff works on platforms I cannot test on.
JamesNC
  • Comment on Re: Re: Re: capture output of a daemon in a tk widget on win32

Replies are listed 'Best First'.
Re: Re: Re: Re: capture output of a daemon in a tk widget on win32
by xiper (Friar) on Mar 24, 2004 at 22:35 UTC
    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 ]
    <pause for 10 seconds>
    read_stdout() sysread() got 9 bytes: [stdout3 ] read_stdout() sysread() got 9 bytes: [stdout4 ] read_stdout() sysread() got 0 bytes: []

    - ><iper

    use japh; print;
      I would use POE then... :0)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://339543]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (5)
As of 2024-04-19 15:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found