Wow, all sorts of ideas, suggestions, brickbats and the like.

Makes me feel right at home, I used to moderate a flight simulation forum for a number of years, and thread police were every bit as active there too :<)

OK, clarify, and yes, the point about not knowing the Perl jargon is well made, that's the major hassle, getting to know the terminology of the language.

I perhaps understated a few things, in that while Perl, HTML and related language use is new to me, on line real time transaction processing and programming is not, I've been doing that for over 20 years, albeit on different hardware and software.

On the mini, we completed a screen, sent it to the processor, and it ran a thread, (stateless) which at the end probably sent some form of response back to the user, sometimes with data embedded, sometimes as a data collection screen, sometimes both. So far, identical to what is happening on the server, albeit different languages and communications protocol.

One of the things we could also do was to start an asynchronous thread/task that did not return to the user but did whatever it was supposed to, and then exited.

In this case, it was a short task, designed to reduce the response time to the user, by dealing with the less urgent stuff at a lower priority, or in a lower priority thread process routine

Yes, we could also run large "batch" type jobs using a similar system, but the constraint there was things like record and file locking implications, so the "batch" jobs usually had to all share one thread and were queued, to avoid deadly embrace conflicts, and in some cases, they were set to run on a very delayed basis, like after the on line day was completed.

That's the other difference, there's no such concept in web work, as it's 24/7 unless the server is taken off line for some reason

So, I'd like to be able to do something like the first thread concept, so my logic flow is:-

collect screen input,
validate,
create some DB records or whatever,

set up the mail "screen" record, and start that process, (it might well queue depending on the host machine)

complete the main line task,
refresh the user screen with the result of the transaction and finish this thread.


If it's uniprocessing threads, as soon as that finished, the mail process loads, executes and exits, happy unless something nasty has happened.
The beauty of that is that the identical process/program/screen can be used stand alone to generate a copy of the original, without any extra code, and testing it a lot simpler, as it's stand alone, with no other integration to worry about, and implementing it in the larger thread is simply a case of define the buffer, load the variables in to it, associate it with the thread and then submit it by whatever means the system supports.

The other advantage is that I've sent the user the response and then I deal with the internal housekeeping stuff that needs to be done, without making the user wait for the response, which keeps the user happy, as the response time is shorter.


As far as I can see, that's not Fork, in that I don't want to run another copy of the same thread, and (terminology again) I don't know what else it might be described as in order to search CPAN, which believe me, I have been doing, with considerable success and a few dissapointments along the way. On the mini, it was a background thread, but in every other respect, it's just another script being activated, but instead of coming from a browser, it's coming from the application itself

Yes, I could run it as a subroutine from a library file, and just include it at runtime, but I still then have to have a front end screen to test it, and do the other things, wheras if I can create it as a complete script, it make for less work, maintenance and documentation, all of which I will appreciate as this thing grows over time, and believe me, it will. I also lose the response time advantage by running it as a sub

And to the cynic who suggested forget the original and start again, not an option, it's been live for 3 days, and we've taken 15 orders from a cold start, and while I know there are several things that I will be very definitely changing as time goes on, and I get to understand Perl better, the underlying HTML and end user "feel" will not be changing much, as the response we've had so far is very positive.

Relational database, Global positioning, user history, previous order recall, real time link to delivery drivers, it's all been thought through, and will happen, now that it's earning money.

Thanks guys and gals, hope this makes what I want to do a bit clearer

Cheers

Steve

In reply to Re^2: Very new to PERL, want to see if CGI spawn concept is possible and or feasible without major pain by IrishSteve
in thread Very new to PERL, want to see if CGI spawn concept is possible and or feasible without major pain by IrishSteve

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.