Message from discussion
more vtables
Newsgroups: perl.perl6.internals
Path: g2news1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <l...@toetsch.at>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 11581 invoked from network); 2 Nov 2004 09:04:07 -0000
Received: from x1.develooper.com (63.251.223.170)
by lists.develooper.com with SMTP; 2 Nov 2004 09:04:07 -0000
Received: (qmail 12953 invoked by uid 225); 2 Nov 2004 09:04:07 -0000
Delivered-To: perl6-intern...@perl.org
Received: (qmail 12949 invoked by alias); 2 Nov 2004 09:04:07 -0000
X-Spam-Status: No, hits=-4.9 required=8.0
tests=BAYES_00
X-Spam-Check-By: la.mx.develooper.com
Received: from mail.nextra.at (HELO mail.nextra.at) (195.170.70.19)
by la.mx.develooper.com (qpsmtpd/0.27.1) with ESMTP; Tue, 02 Nov 2004 01:04:03 -0800
Received: from lux.leo.home (at24a01-dial-161.nextranet.at [195.170.73.161])
by mail.nextra.at (8.13.1/8.13.1) with ESMTP id iA293q72026304;
Tue, 2 Nov 2004 10:03:55 +0100 (MET)
Received: from thu8.leo.home (thu8.leo.home [192.168.1.5])
by lux.leo.home (Postfix on linux 2.0.36 (i386)) with ESMTP
id B2483118024; Tue, 2 Nov 2004 09:43:26 +0100 (MET)
Received: (from lt@localhost)
by thu8.leo.home (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) id iA28fgb06378;
Tue, 2 Nov 2004 09:41:42 +0100
Message-ID: <200411020841.iA28fgb06378@thu8.leo.home>
To: d...@sidhe.org (Dan Sugalski)
Subject: Re: more vtables
In-Reply-To: <a0620060bbdac4919b192@[10.0.1.3]>
References: <41869682.6060300@toetsch.at> <a0620060bbdac4919b192@[10.0.1.3]>
Reply-To: l...@toetsch.at
Cc: perl6-intern...@perl.org
Date: Tue, 2 Nov 2004 09:41:42 +0100
Approved: n...@nntp.perl.org
From: l...@toetsch.at (Leopold Toetsch)
Dan Sugalski <d...@sidhe.org> wrote:
> At 9:03 PM +0100 11/1/04, Leopold Toetsch wrote:
>>We need more vtables.
>>
>>* INTVAL hash()
>>
>>To properly support Python, we need:
>>- a hash PMC that isn't restricted to STRING* keys
> Works for me. We probably need to make sure that everything's in
> place for keys to tag the individual key elements properly too.
There is one entry in the hash structure:
Hash_key_type key_type;
That should suffice. I don't think, we should mix STRING and PMC keys in
one hash - or only with care: a STRING "foo" and a String PMC "foo" hash
to the same hash value. An Integer PMC C<1> and a STRING key "1" are
different.
>>* void finalize()
>>
>>We should separate finalize() from the destroy() vtable.
> Any reason that the destroy entry's insufficient? That's what I'd
> intended it to do, at least.
These two have different usage patterns.
destroy() is needed commonly to free memory. finalize() is currently
needed to close file handles and clear active timer PMCs.
> I can see thinking about changing the scheme we use to destroy
> things, certainly (like, say, putting the pmcs that need destruction
> in a queue, tagging them as having been queued, run the queue and
> trigger the destroy method, tag them as having been destroyed, then
> if they come up as dead in the next round of DOD assume they're
> garbage), but I'm not sure we need to split finalization and
> destruction.
When we have objects with finalizers, we have to run the finalizers in
order from most derived down the parent chain. So as you state, we've to
defer destruction, store these objects with finalizers somewhere, sort
them, run user code to finalize objects and so on.
Doing that all in the destroy vtable is tedious especially, when user
code is involved too. The finalize vtable is overridable, the destroy
isn't. A split makes this functionality much cleaner.
leo
|
