in reply to Re^3: symbols, scope, and mod_perl
in thread symbols, scope, and mod_perl

You are right. To be more precise, I am actually allocating the object on thread symbol table, but under mod_perl objects in "main" threads functions are persistent between calls. So it gets messed on subsequent calls. To avoid this it is needed to use a lexical variable, that does not allocate on the symbol table. To achieve the same behavior as per cgi environment, I should manipulate what it is called "stack scratchpad", but I do not have such skills.

Replies are listed 'Best First'.
Re^5: symbols, scope, and mod_perl
by Anonymous Monk on Oct 01, 2012 at 12:11 UTC

    Well, you really shouldn't be exporting this object if its not a singleton

    use EXAMPLE();
my $poop = EXAMPLE->new;
$poop->my_example_method;
print "mission accomplished\n";

    [download]
[reply]
[d/l]
      If you have a look at the code I posted, you can see that the trick I am testing consists actually in putting an instance of the object in the "main" namespace without using Exporter and without declaring/instantiating the object from the cgi. In fact the class calls its own constructor when you use it.
[reply]
[d/l]

        If you have a look at the code ...

        What makes you think I did not?

        I did look, I even ran the code, and I even had no problem with it like I showed

[reply]
Re^5: symbols, scope, and mod_perl
by Anonymous Monk on Oct 01, 2012 at 12:09 UTC

    You are right. ...

    Are you saying you're using threads in your program?

[reply]
      I am testing the trick also in mod_perl, under Worker MPM. So, yes, I am definitely using threads.
[reply]

        I am testing the trick also in mod_perl, under Worker MPM. So, yes, I am definitely using threads.

        So you're not using threads, the perl module

[reply]

In Section Seekers of Perl Wisdom