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

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

Nice code xiper.
I tried making it work, but unfortunately the only thing I've discovered is that only the last handler/callback to be declared will be active. On my computer ( win2k, perl 5.8 ) the code only prints out the stderr messages, when reversed with stdout - it only gets the stdout messages.

My site

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

Replies are listed 'Best First'.
Re: Re: capture output of a daemon in a tk widget on win32 by xiper (Friar) on Mar 24, 2004 at 04:54 UTC
Hmm, you appear to be right. I found this in Tk::fileevent: The readable and writable event handlers for a file are independent, and may be created and deleted separately. However, there may be at most one readable and one writable handler for a file at a given time in a given interpreter. If fileevent is called when the specified handler already exists in the invoking interpreter, the new callback replaces the old one. Not sure if "file" means filehandle tho'... Note also how the last callback gets fired 4 times, but only twice with data waiting... Different combinations of prints in the child result in generally inconsistent behaviour (that is, incidentally, consistent with blocking/buffering/deadlock type problems). My output: `read_stderr() sysread() got 9 bytes: [stderr1 ] read_stderr() sysread() got 9 bytes: [stderr2 ] read_stderr() sysread() got 0 bytes: [] read_stderr() sysread() got 0 bytes: []` [download] - ><iper `use japh; print;` [download]	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: capture output of a daemon in a tk widget on win32
by xiper (Friar) on Mar 24, 2004 at 04:54 UTC

The readable and writable event handlers for a file are independent, and may be created and deleted separately. However, there may be at most one readable and one writable handler for a file at a given time in a given interpreter. If fileevent is called when the specified handler already exists in the invoking interpreter, the new callback replaces the old one.

Note also how the last callback gets fired 4 times, but only twice with data waiting... Different combinations of prints in the child result in generally inconsistent behaviour (that is, incidentally, consistent with blocking/buffering/deadlock type problems).

My output:

read_stderr()
sysread() got 9 bytes:
[stderr1

]
read_stderr()
sysread() got 9 bytes:
[stderr2

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

- ><iper

use japh; print;
[download]

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom