Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41D5E26B.4000709@stason.org>
Date: Fri, 31 Dec 2004 18:36:11 -0500
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Stas Bekman <stas@stason.org>
Cc: Joe Schaefer <joe+gmane@sunstarsys.com>, dev@perl.apache.org
Subject: Re: [mp2] pool object dependant methods insanity
References: <41C4640A.4030701@stason.org> <41C8D0CE.30704@stason.org>
 <87hdmfghmp.fsf@gemini.sunstarsys.com> <41C8E581.1070603@stason.org>
 <87acs7gd8t.fsf@gemini.sunstarsys.com> <41CC631D.5050205@stason.org>
 <87vfaredjq.fsf@gemini.sunstarsys.com> <41CC675C.2070704@stason.org>
 <41CC7200.20701@stason.org>
In-Reply-To: <41CC7200.20701@stason.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stas Bekman wrote:
> while I can easily reproduce the problem with 
> APR::Bucket::alloc_create(APR::Pool->new);
> the case with setaside is not clear. I've tried the following:

> +    # setaside + alloc_create on out-of-scope pools
> +    {
> +        my $data = "A" x 10;
> +        my $orig = $data;
> +        #$ba = APR::Bucket::alloc_create(APR::Pool->new);
> +        my $b = APR::Bucket->new($ba, $data);
> +        my $status = $b->setaside(APR::Pool->new);
> +        ok t_cmp $status, 0, "setaside status";
> 
> +        # try to overwrite the temp pool data
> +        require APR::Table;
> +        my $table = APR::Table::make(APR::Pool->new, 50);
> +        $table->set($_ => $_) for 'aa'..'za';
> +
> +        # now test that we are still OK
> +        $b->read(my $read);
> +        ok !t_cmp($read, $data,
> +                 "data inside the setaside bucket is unaffected by " .
> +                 "changes to the Perl variable it's created from");
> +        $b->destroy;
> +    }
> +
>      APR::Bucket::alloc_destroy($ba);
> 
>  }
> 
> but it doesn't break. Further looking at the source code,
> 
>   $b->setaside(APR::Pool->new);
> 
> doesn't replace $b to a new bucket allocation. I think this is why I 
> can't reproduce the problem.

That wasn't correct.

Here is the real reason why the problem can't be created with a temp pool:

Index: xs/APR/Bucket/APR__Bucket.h
===================================================================
--- xs/APR/Bucket/APR__Bucket.h (revision 123827)
+++ xs/APR/Bucket/APR__Bucket.h (working copy)
@@ -112,8 +112,11 @@
      if (GIMME_V == G_VOID && rc != APR_SUCCESS) {
          modperl_croak(aTHX_ rc, "APR::Bucket::setaside");
      }
-
-    //mpxs_add_pool_magic(b_sv, p_sv);
-
+
+    /* No need to call mpxs_add_pool_magic(b_sv, p_sv); since
+     * pool_bucket_cleanup is called by apr_bucket_pool_make (called
+     * by modperl_bucket_sv_setaside) if the pool goes out of scope,
+     * copying the data to the heap.
+     */
      return rc;
  }

so setaside does not need a special handling. I live the test that would 
have failed if it wasn't for apr internal's backup. so if it ever removed 
the test should catch it.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org