Newsgroups: perl.perl6.internals
Path: g2news1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <n...@flirble.org>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 31210 invoked from network); 14 Jun 2004 13:34:05 -0000
Received: from x1.develooper.com (63.251.223.170)
  by onion.develooper.com with SMTP; 14 Jun 2004 13:34:05 -0000
Received: (qmail 13539 invoked by uid 225); 14 Jun 2004 13:34:04 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 13534 invoked by alias); 14 Jun 2004 13:34:04 -0000
X-Spam-Status: No, hits=-4.9 required=8.0
	tests=BAYES_00
X-Spam-Check-By: la.mx.develooper.com
Received: from plum.flirble.org (HELO plum.flirble.org) (195.40.6.20)
  by la.mx.develooper.com (qpsmtpd/0.27.1) with ESMTP; Mon, 14 Jun 2004 06:34:01 -0700
Received: from nick by plum.flirble.org with local (Exim 3.20 #3)
	id 1BZrb4-000KNW-00
	for perl6-intern...@perl.org; Mon, 14 Jun 2004 14:33:58 +0100
Date: Mon, 14 Jun 2004 14:33:58 +0100
To: perl6-intern...@perl.org
Subject: Re: Making PMCs
Message-ID: <20040614133358.GJ1147@plum.flirble.org>
Mail-Followup-To: perl6-intern...@perl.org
References: <20040613100125.GG81272@plum.flirble.org> <40CC9485.6030807@sccs.swarthmore.edu> <a06110400bcf34fb7bef4@[10.0.1.3]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a06110400bcf34fb7bef4@[10.0.1.3]>
User-Agent: Mutt/1.3.25i
X-Organisation: Tetrachloromethane
Sender: Nicholas Clark <n...@flirble.org>
X-Spam-Rating: onion.develooper.com 1.6.2 0/1000/N
Approved: n...@nntp.perl.org
From: n...@ccl4.org (Nicholas Clark)

On Mon, Jun 14, 2004 at 08:53:10AM -0400, Dan Sugalski wrote:
> At 12:53 PM -0500 6/13/04, Matt Fowles wrote:
> >Nicholas~
> >
> >I will try to answer what I can, based on my current experience 
> >making those array PMCs.
> >
> >
> >Nicholas Clark wrote:
> >
> >>a data pointer
> >>	which I can use. I am always responsible for freeing anything 
> >>	there(?)
> >>	and to do this I need to set the active destroy flag(?)
> >>	This flag is not the same as the high priority DOD system(?)
> >>	Does the garbage collector ever consider this pointer?
> >>	Does it ever chase what it points to?
> >>
> >You are responsible for freeing it by setting the active destroy flag.
> 
> Well... no. You're not. If the memory hanging off the data pointer 
> was allocated from one of parrot's managed pools (either free memory 
> or pmc/buffer header) then you don't have to free it.

There's a memory internals document, but I can't spot any document given
an API overview on how to allocate memory this way.

The implication of what you're saying is that the data pointer is checked by
the DOD, and any PMC it points directly to isn't dead.

Nicholas Clark