On 5/24/07, Mark Henry <[EMAIL PROTECTED]> wrote:
what I've done instead is have a single script, which based on a hidden field in a form, figures out where execution should resume, and for every re-invocation of the script, the data structures would (should?) be reloaded anew.
That sounds reasonable, but it's hard for me to interpret what you're saying here without seeing code or hearing specifics. You might mean something totally different from what I'm picturing.
I have however now run into segmentation faults if I use the back button and resubmit a form (for what reason I dont know).
You should track this down. Usually this means you have a bug where you put some XS structure like a request object ($r) in a global variable and tried to use it later on a different request. Can you always trigger a segfault with a specific series of actions?
how are my data structures being created/destroyed etc.., that is, for each invocation of the script (as it progresses through my 'phases' or more unpredictably a back/resubmit) is there not a new process assigned to each invocation, and thereby seperate in-memory locations for those (redundant but safe) data structures ? (which should avoid memory corruption)
The basic idea is that apache on unix systems will have multiple child processes, each with their own perl interpreter inside, and each in their own memory space. You have no control over which one from this pool will handle any given request. Data that you put in perl globals will persist across requests, since the interpreter does not get torn down between requests.
p.s. when does a mod_perl proc die?
The apache lifecycle is pretty well-documented. There are a few reasons apache will kill a child process. When it does, the perl interpreter is shut down. - Perrin
