Re: capturing output from running process crashes gtk2
- From: zentara <zentara1 sbcglobal net>
- To: gtk-perl-list gnome org
- Subject: Re: capturing output from running process crashes gtk2
- Date: Wed, 2 Aug 2006 09:33:42 -0400
On Wed, 2 Aug 2006 14:50:37 +0200
"Ratcliffe, Jeffrey (Peters)" <Jeffrey Ratcliffe External eads com> wrote:
It can not work this way. You need to start the sub process
so that it writes to a pipe, then add the pipe's filehandle
as an IO channel to the Glib/Gtk main loop. All processing
of input from the pipe must be done from the IO channel's
callback (careful here: you must only use non-blocking reads in
this context). Rather advanced stuff, extra credit for
getting the corner cases (e.g. killing the sub process) right.
Right. Almost there. The following script works, but gives me the warning "Name "main::WRITE" used only
once: possible typo at ./test_dialog3 line 23." If I replace \*WRITE with 0, then I get the error message
"open3: close(0) failed: Bad file descriptor at ./test_dialog3 line 23".
How do I write it so as to avoid the warning?
You can't. As I was experimenting yesterday on how to control scanimage
thru IPC, I wanted to see if I could make a button press send a Control-D to
stop the scan. (Remember the clumsy Control-C conversion I did?).
Well a smart monk on http://perlmonks.org explained that the Control-D actually
closes the WRITE filehandle, which tells the scan to stop.
So this is the way scanimage works. It monitors the WRITE filehandle, which is
it's stdin. As long as it's open, it will send messages to it's stderr in batch mode,
when it receives any input ( i.e. an ENTER press, or any press) it takes it as an
"okay to start next scan". When the filehandle closes, it will terminate scanimage.
Then you will get a bunch of errors if you don't close the stderr filehandle, because
you are still trying to read it. Also a zombie will be created if you don't kill the $pid
of the scanimage run.
It may be possible to do this with some clever single threaded manipulation, but
I think it would work best in a 2 thread program, using shared variables to communicate.
Joe
--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]