I have approached this problem in a different manner
I have gui.pl start compute.pl via a start system call.
I then have compute.pl write its progress to a file(not at the ms level), and when done write a completion message to that file. I then use another gui (gui2.pl) program to print that file to the browser (this can have a auto refresh if you like). The first gui.pl then tells the browser what the new gui address is (i pass a parm to the gui2.pl that tells it what file to monitor http://../gui2.pl?file=tracker_file). Now i had programs that took days to finish, and that was way beyond the timeout limit of a cgi session, and you wouldnt want an auto refresh either. the user just refreshed the gui2.pl page whenever they wanted to check if its done.system("start perl compute.pl -arg1 arg2 arg3 arg4 sourcefile.txt > de +stinationfile.txt" );
Ive been doing it this way for over a decade. i have little modules that make it easy to do. gui2.pl takes a specially crafted file that contains elements for many table-sections. One section displays timestamps at various milestones (input done@time, first phase done @time...), another section often displays record counts or patient counts as the process continues, and a third section displays informational progress methods. It can have as many tables as you want, and they are displayed in order of the first reference to them. Often i have warning messages displayed first, with a button that can cause the task to be terminated if the user doesnt feel the progress is viable. This requires compute.pl to record its "task id" into the tracking file so gui2.pl knows what to cancel. For the lack of a better name i now call this module websee.pm
This is an example
a line is a ctime, <space> <cmd> <space> <rest>
cmd=$s gives the pid.
cmd=P prints <rest> in the bottom section
cmd=T is a table, <rest> is taken to be a <table-name> <space> <row-name> <space> <col-name> <space> <col-contents>
That produced a simple page, the $s creates the "kill-button" at the top. it exists till it finds the $e line.1483271066 $s 3880 1483271066 1483271066 P started 1483271066 T table step started 2017-01-01-05-44-26 1483271067 T table copied started 000:00:01 000:00:01 1483271067 P d-time:000:00:01 000:00:01->auto:started:copied 1483271067 T table copied ended 000:00:00 000:00:01 1483271067 P d-time:000:00:00 000:00:01->auto:ended:copied 1483271067 T table blind_scrape_4a-setup.pl started 000:00:00 000:00:0 +1 1483271067 P d-time:000:00:00 000:00:01->auto:started:blind_scrape_4a- +setup.pl 1483271067 T table blind_scrape_4a-setup.pl ended 000:00:00 000:00:01 1483271067 P d-time:000:00:00 000:00:01->auto:ended:blind_scrape_4a-se +tup.pl 1483271067 T table blind_scrape_4b-worksish.pl started 000:00:00 000:0 +0:01 1483271067 P d-time:000:00:00 000:00:01->auto:started:blind_scrape_4b- +worksish.pl 1483271701 T table blind_scrape_4b-worksish.pl ended 000:10:34 000:10: +35 1483272144 P Ended 1483272145 $e 3880 1483272145
This may be extreme for your case, but it has served me well since the late 90's. Like i said, some jobs ran for days, one ran for a week, Ive used this on windows and unixen. The process of "spawning" the separate command on unixen has used "at" and other queue managers. On windows ive just used start.
In reply to Re: Shared memory and asynchronous access
by huck
in thread Shared memory and asynchronous access
by vef445
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |