in reply to User Feedback for Subroutines with Long Execution Time

You can get a wget style progress bar here. Although the easiest thing is to get the long running sub to write to the console if you want it's parent/some other process to do the progress bar you need some sort of IPC perlman:perlipc.

The simplest solution is to have the long running widget update a semaphore file with a number ie how many % or whatever it has done so far. The process you want to do the progress bar just reads the file to get the info it needs. Provided the process generating the progress bar knows what this file will be called you have no problem. Delete this semaphore file when finished to indicate the completed status. There are literally dozens of other methods to do IPC, but at the pace you are talking about a file is the quickest solution and will be efficient enough (ie the overhead will not kill you).

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

  • Comment on Re: User Feedback for Subroutines with Long Execution Time

Replies are listed 'Best First'.
Re: Re: User Feedback for Subroutines with Long Execution Time
by halley (Prior) on May 29, 2003 at 15:27 UTC

    In a similar project, I wanted to run an arbitrary subprocess that wasn't designed with progress in mind. I relied on the parent (progress monitoring) process having either (1) an initial guess as to the number of lines of STDOUT output, or (2) a process-specific way of converting a line of STDOUT output into a percent-complete guess.

    For example, to monitor a long tar jcvf $date.home.tar.bz2 /home process, you can either figure out how many files that tar will have to process and then count actual output lines, or you can try to watch the naturally sorted filenames ("./meetings/..." is roughly halfway through the alphabet) for a gut-check guess.

    --
    [ e d @ h a l l e y . c c ]