As mentioned by another poster(and a good point), there is in fact, a lot of 'prior art' out there.
Also, as mentioned by yet another poster, there are in fact existing schedulers which would handle this.
What you propose is certainly doable with Perl(and others). Again, I have to wonder how long the user will be waiting.
If the user is expected to wait a few seconds, no problem. If longer...? Regardless, I personally would have Perl put out
that "please wait for..." page. Your back-end knows what is going on, let it inform the front end. There is no penalty that I can
think of for doing it that way. To keep the user more or less engaged, have Perl spit out some javascript which probes the server
for the state of the job and updates the user every 10 seconds or so... Just a thought... .
...the majority is always wrong, and always the last to know about it...Insanity: Doing the same thing over and over again and expecting different results...
| [reply] |
You may be interested in Data::GUID for generating your unique process ID.
If your processing code runs on a single system you can use PIDs to uniquely identify currently running processes. If you are running across a number of systems use a GUID to identify a task and map that to a system name and PID to allow monitoring task progress. This stuff is commonly enough done that much of it is likely already provided in a module, but my quick CPAN search didn't turn up anything promising.
Perl is the programming world's equivalent of English
| [reply] |
What I am thinking to do is have a random-string generator subroutine, so that the files generated for each user are separated from those of the others. Sound reasonable approach?
It may seem like that now, but don't do this. Sooner or later the generator will repeat one of the random strings and then the trouble begins. Better to use a truly unique identifier (which could be as simple as an incrementing integer).
| [reply] |