at(1) is a Unix command to start a process.
Assuming you're on a Unix/Linux box, type "man at" to get the story.
A cleanup handler is more pleasant than a prostate exam.
You can spend your life waiting for others. Just write a
routine called "cleanup" and have it do something like
make a log en
Sorry, I couldn't figure out what at(1) meant (or maybe ap(1) which you
say below) is that an abbreviation for something?
And Perrin saying "cleanup handler" is right up there with "prostate
exam" in my list of things to get into, both scare me!
Of course at some point a man needs to do both.
You made no comment on the links I sent you earlier today.
They had lots of good advice. Particularly the first one
suggested not forking the Apache process, but using an
ap(1) call to start a process to do the additional processing.
OK, the ap(1) alternative was a bit light on details.
How abo
Ok, then maybe I need to supply some code here to try and get clarification:
mailfile.pl
###
use strict;
...
use POSIX;
#gather needed modules and objects
my $fileOBJ = new MyOBJS::FILE($in->param('id'));
my $clientOBJ = new ...
my $userOBJ = new ...
# All OBJjects have a {DBH} property
On Mon, Jan 25, 2010 at 3:48 PM, Tosh Cooey wrote:
> Thanks Perrin, the forking, my child got a PID of 30033 and then afterwards
> when I checked the processes (ps) for 30033 I see:
>
> [apache2]
>
> Is that what's supposed to happen?
After you call exit? No. It should be gone. That's a zombi
Perrin Harkins wrote:
On Mon, Jan 25, 2010 at 2:41 PM, Tosh Cooey wrote:
Just to follow up on this before anyone spends any time caring about it, the
seg faults could also be because one of the zombie apache2 processes I've
spawned like a Gremlin is answering the request and well...
I don't t
On Mon, Jan 25, 2010 at 2:41 PM, Tosh Cooey wrote:
> Just to follow up on this before anyone spends any time caring about it, the
> seg faults could also be because one of the zombie apache2 processes I've
> spawned like a Gremlin is answering the request and well...
I don't think so. That's not
Just to follow up on this before anyone spends any time caring about it,
the seg faults could also be because one of the zombie apache2 processes
I've spawned like a Gremlin is answering the request and well...
So, if I've done the fork properly and pretend I have apache PIDs 1..10
running, an
On 01/25/2010 02:12 PM, Tosh Cooey wrote:
Just to make things stranger, after I make a fork and things don't
happen the way I expect them, subsequent calls to other programs running
under mod_perl are generating Segmentation Faults. This could be due to
the fact that the server is running in Eur
I wish I could do SQL before the fork, but I need to update tables with
results in the forks.
Just to make things stranger, after I make a fork and things don't
happen the way I expect them, subsequent calls to other programs running
under mod_perl are generating Segmentation Faults. This cou
Have you been through these threads already?
The first one seems quite like what you're doing.
http://mail-archives.apache.org/mod_mbox/perl-modperl/200908.mbox/%
3c59a07310908250820m1f789901g22eece5b2897c...@mail.gmail.com%3e
http://www.gossamer-threads.com/lists/modperl/modperl/100099
Is the
Sorry, I forgot to mention I checked InactiveDestroy as well, but since
my parent sends a 302 redirect to the browser right away and nothing
else is done in the parent I don't think that's the culprit.
Thanks for reminding me!
Tosh
Dami Laurent (PJ) wrote:
-Message d'origine-
De
>-Message d'origine-
>De : Tosh Cooey [mailto:t...@1200group.com]
>Envoyé : lundi, 25. janvier 2010 17:08
>À : modperl@perl.apache.org
>Objet : mod_perl2 + fork + DBI = Chaos
>
>My application-from-hell is doing odd things probably related to the
>above storms and culminating in a perf
My application-from-hell is doing odd things probably related to the
above storms and culminating in a perfect storm.
Can anyone point me to resources outlining the best way to use the
combination in the subject line?
There seems to be many ways of accomplishing specifics but very little
gen
14 matches
Mail list logo