Subject: Re: forking an external process - msg#00022

Previous Message by Date:

Re: forking an external process

On Tue, 2002-05-07 at 16:04, Kim Schulz wrote: > hi > > I want my gui to be accesable even when an external process is doing > some work. > My program does the following: > initialise the GUI > exec of a wget process > wait for it to return > do somthing to the return which will update the GUI (add rows to a > clist) > > as it is now it hangs while the wget process is running. I have tried to > fork it but it doesnt work: <snip /> That depends on your definition of works. When you fork a process it splits into two independent process. The split occurs at the fork and the only difference between the two processes is that one gets a return of 0 from fork and the other gets the PID of the other process. So what happend in your code was one process exec'ed wget and the other ran parse_xml(). What you need to look into is inter-process communication (perldoc perlipc). Luckily Gtk provides a mechanism for monitoring files (and consequently sockets since they are just specialized files): Gtk::Gdk->input_add. -- Today is Boomtime the 54th day of Discord in the YOLD 3168 Missile Address: 33:48:3.521N 84:23:34.786W

Next Message by Date:

Re: forking an external process

On Tuesday 07 May 2002 9:04 pm, you wrote: > hi > > I want my gui to be accesable even when an external process is doing > some work. > My program does the following: > initialise the GUI > exec of a wget process > wait for it to return > do somthing to the return which will update the GUI (add rows to a > clist) > > as it is now it hangs while the wget process is running. I have tried to > fork it but it doesnt work: > sub getnews{ > $clist->clear(); > if (fork() == 0) { > exec("wget http://www.slashdot.org/slashdot.rdf -nv -q -O \ > slashdot.rdf"); > exit(0); > } > parse_xml(); > } > > what have I done wrong? the parse_xml part is only to be runned when the > exec has returned somthing As others have said all that is needed, I'll just add some problems you probabley won't know about so get confused/worried/want to kill perl when you come across them: In any perl: forked processes become zombies after they die, and send a SIGCHLD to the main process (I'm assuming unix as you are using wget) and you have to reap your zombies, this is mentioned in the 'camel' book near forking, so it should be easy to find more indepth information I would guess, if you can't find any, mail me and I'll be happy to spend some time explaining. With GTK and perl you have to use _exit() to exit a fork, due to some complex reason, otherwise you get some horrid errors about x libaries and you get all confused (at least I did). Toby

Previous Message by Thread:

Re: forking an external process

On Tue, 2002-05-07 at 16:04, Kim Schulz wrote: > hi > > I want my gui to be accesable even when an external process is doing > some work. > My program does the following: > initialise the GUI > exec of a wget process > wait for it to return > do somthing to the return which will update the GUI (add rows to a > clist) > > as it is now it hangs while the wget process is running. I have tried to > fork it but it doesnt work: <snip /> That depends on your definition of works. When you fork a process it splits into two independent process. The split occurs at the fork and the only difference between the two processes is that one gets a return of 0 from fork and the other gets the PID of the other process. So what happend in your code was one process exec'ed wget and the other ran parse_xml(). What you need to look into is inter-process communication (perldoc perlipc). Luckily Gtk provides a mechanism for monitoring files (and consequently sockets since they are just specialized files): Gtk::Gdk->input_add. -- Today is Boomtime the 54th day of Discord in the YOLD 3168 Missile Address: 33:48:3.521N 84:23:34.786W

Next Message by Thread:

Re: forking an external process

On Tuesday 07 May 2002 9:04 pm, you wrote: > hi > > I want my gui to be accesable even when an external process is doing > some work. > My program does the following: > initialise the GUI > exec of a wget process > wait for it to return > do somthing to the return which will update the GUI (add rows to a > clist) > > as it is now it hangs while the wget process is running. I have tried to > fork it but it doesnt work: > sub getnews{ > $clist->clear(); > if (fork() == 0) { > exec("wget http://www.slashdot.org/slashdot.rdf -nv -q -O \ > slashdot.rdf"); > exit(0); > } > parse_xml(); > } > > what have I done wrong? the parse_xml part is only to be runned when the > exec has returned somthing As others have said all that is needed, I'll just add some problems you probabley won't know about so get confused/worried/want to kill perl when you come across them: In any perl: forked processes become zombies after they die, and send a SIGCHLD to the main process (I'm assuming unix as you are using wget) and you have to reap your zombies, this is mentioned in the 'camel' book near forking, so it should be easy to find more indepth information I would guess, if you can't find any, mail me and I'll be happy to spend some time explaining. With GTK and perl you have to use _exit() to exit a fork, due to some complex reason, otherwise you get some horrid errors about x libaries and you get all confused (at least I did). Toby