[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About shared substrings
From: |
Tom Lord |
Subject: |
Re: About shared substrings |
Date: |
Fri, 16 Jan 2004 14:00:27 -0800 (PST) |
> From: Roland Orre <address@hidden>
> I discussed this issue with Mikael Djurfeldt today and then he came up
> with the following solution:
> SCM substring_table;
> SCM scm_make_shared_substring (SCM parent, SCM start, SCM end)
> {
> SCM substring;
> char *mem;
> int c_start, c_end;
> SCM_VALIDATE_SUBSTRING_SPEC_COPY (1, parent, mem,
> 2, start, c_start,
> 3, end, c_end);
> substring = scm_cell (SCM_MAKE_STRING_TAG (c_end - c_start),
> (scm_t_bits) (mem + c_start));
> scm_hash_set_x (substring_table, substring, parent);
> return substring;
> }
> where the following is put in the main:
> substring_table
> = scm_permanent_object (scm_make_weak_key_hash_table (SCM_UNDEFINED));
> This is almost magical :) It works perfectly well and I don't need to
> bother about any explicit deallocation. This is also the first time I
> really understand the purpose of these weak hash tables. For weak hash
> tables the hash entry will be garbage collected first when the key is
> seen as garbage. With this scheme we still have the same essential
> functionality from my perspective about shared substrings but we do
> no longer need an explicit tag for shared substrings.
How can this actually work?
It ensures that SUBSTRING, while live, protects PARENT. I see that
and it's _roughly_ what's wanted.
But SUBSTRING is tagged as a string, no? When that key (the
substring) is collected -- won't that lead to a bogus free of the
substring data?
(I'm looking at the 1.6.4 GC implementation. Apologies if things have
changed in some significant way in 1.7)
-t