Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> There's no reason why the other scheme (whatever it is) can't be either
> frequent DoD runs or my hybrid refcounting/dod scheme.
Frequent DOD runs are not a problem for an average program (for some
definition of average). But when we come to ~1 milli
Matt Fowles wrote:
>
> Benjamin Goldberg wrote:
> >>For more complex cases timely destruction will not be assured.
> >
> > Which is not-so-good. We'd like timely destruction *always*
> >
> > However, given that your suggestion can be implemented purely
> > through compile time behaviors, there'
At 10:01 AM -0500 6/4/03, Garrett Goebel wrote:
From: Graham Barr [mailto:[EMAIL PROTECTED]
I may be missing something here. But within the resources of
an object may be other PMCs. As those PMCs will not be referenced
from anywhere else what is to stop the DoD run from freeing those
before it
From: Graham Barr [mailto:[EMAIL PROTECTED]
>
> I may be missing something here. But within the resources of
> an object may be other PMCs. As those PMCs will not be referenced
> from anywhere else what is to stop the DoD run from freeing those
> before it freed the object ?
Putting my head out o
Graham Barr <[EMAIL PROTECTED]> wrote:
> I may be missing something here. But within the resources of an object may
> be other PMCs. As those PMCs will not be referenced from anywhere else
> what is to stop the DoD run from freeing those before it freed the object ?
If the PMC has explicit knowle
On Wed, Jun 04, 2003 at 11:05:34AM +0200, Leopold Toetsch wrote:
> Graham Barr <[EMAIL PROTECTED]> wrote:
>
> > I ask becasue what happens if an object actually wants
> > to use its contents during its DESTROY ?
>
> > For example Net::POP3::DESTROY will send a reset command to its
> > server if t
Graham Barr <[EMAIL PROTECTED]> wrote:
> I ask becasue what happens if an object actually wants
> to use its contents during its DESTROY ?
> For example Net::POP3::DESTROY will send a reset command to its
> server if the user did not call the quit method first. But how
> could it do this if the s
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Benjamin Goldberg wrote:
>>
>>> If a PMC was found to be reachable through a non-refcounted variable,
>>> then we set a flag saying so. At the end of DoD, every reachable
>>> refcounted value which has the first flag set, but
On Tue, Jun 03, 2003 at 07:24:04PM -0400, Benjamin Goldberg wrote:
> IIRC, DoD normally happens something vaguely like this:
>
>for my $p (@all_pmcs) {
> clear_is_live_flag($p);
>}
>our $traverse;
>sub set_is_live_flag($p) {
> if( !test_is_live_flag($p) and test_is_agre
Benjamin Goldberg wrote:
For more complex cases timely destruction will not be assured.
Which is not-so-good. We'd like timely destruction *always*
However, given that your suggestion can be implemented purely through
compile time behaviors, there's no reason we can't use what you've
suggested fo
Matt Fowles wrote:
>
> All~
>
> I have been following the whole GC/timely destruction thing for a
> while and have a few questions/observations.
>
> Most of the ref counting systems provide for very simple ref counting
> containers and, essentially, provide timely destruction for the simple
> ca
On Tue, 3 Jun 2003, Matt Fowles wrote:
> Most of the ref counting systems provide for very simple ref counting
> containers and, essentially, provide timely destruction for the simple
> case where a variable is not placed into some more complicated
> container. It seems to me that if we are worri
All~
I have been following the whole GC/timely destruction thing for a while
and have a few questions/observations.
Most of the ref counting systems provide for very simple ref counting
containers and, essentially, provide timely destruction for the simple
case where a variable is not placed i
After reading Leopold Toetsch's post, I'm going to simplify part of my
proposal slightly.
Benjamin Goldberg wrote:
[snip]
> To avoid premature cleanup, any time that the contents of a
> refcounted variable is assigned to a non-refcounted variable, an
> opcode to set a "reachable by non-refcounted
Miko O'Sullivan wrote:
>
> On Mon, 2 Jun 2003, Benjamin Goldberg wrote:
>
> > All values needing timely destruction would inherit from a class
> > RefCounted.
>
> I like this concept a lot, but maybe we can take it a little further
> and make it transparent to the programmer. Suppose that the
Leopold Toetsch wrote:
> Benjamin Goldberg wrote:
>
>> I'd like to reiterate (and clarify) my idea, of a hybrid scheme
>> combining refcounting and DoD.
>
> I'll try to translate this to parrot speak. I hope that I fully
> understand your scheme, but lets see.
[snip]
>> During the course of a DoD
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> I'd like to reiterate (and clarify) my idea, of a hybrid scheme
> combining refcounting and DoD.
I'll try to translate this to parrot speak. I hope that I fully
understand your scheme, but lets see.
> All values needing timely destruction would inhe
On Mon, 2 Jun 2003, Benjamin Goldberg wrote:
> All values needing timely destruction would inherit from a class
> RefCounted.
I like this concept a lot, but maybe we can take it a little further and
make it transparent to the programmer. Suppose that the internals only
tracked objects that have
Piers Cawley wrote:
>
> The Perl 6 Summary for the week ending 20030601
> Another Monday, another Perl 6 Summary. Does this man never take a
> holiday? (Yes, but only to go to Perl conferences this year, how did
> that happen?)
>
> We start with the internals list as usual.
>
>
19 matches
Mail list logo
