Leopold Toetsch wrote:
>
> We currently have constant Key and Sub PMCs both created from the
> packfile at load time. They live in the constant_table pointing to a
> constant PMC pool. But we need more.
>
> We have allover the core code like this:
>
> string_from_cstring(interpreter, "pIt", 0)
Don't do that. Instead, do:
string_from_cstring(interpreter, "pIt", PObj_external_FLAG);
This will allow parrot to avoid making a copy of "pIt".
Actually, IMHO, we should disallow (both for this, and for string_make)
a simple default of 0 for 'flags'. Instead, I think we should require
that the programmer explicitly indicate exactly what the pointer we're
passing in is. It could be any of:
A buffer which might be reused by something else, so we should
allocate space, and copy the data into it.
A const static buffer which won't (can't) ever change. We can
capture it and use it, but shouldn't [ever] try altering it.
An external buffer which won't change on us, but which is not
constant memory ... like non-const static memory, or perhaps a string
from a program in which parrot is embedded. We can freely use it
(without copying it) and even change it, but growing it requires that we
allocate from our own arenas. Also, when we no longer need it, just let
go of it.
A buffer allocated by mem_sys_allocate, which the calling function
wants to *give up* to the string. We can use it directly without
copying it, reallocate it as needed, and free it to our memory arenas
when we're done with it. Indeed, by indicating this, it would now be
the string's responsibility to free up the memory when it's gone,
instead of being the caller's responsibility.
If there are any other scenarios, I'm not aware of them.
The majority of calls from user-written C code will be of type 2: A
constant static buffer which won't (can't) ever change (like in your
example). Some user-land code will be type 1 (for example, turning the
result of inet_ntoa into a string).
I'm not sure if type 3 has a use -- one can claim that the string is
type 1, without harm.
There wouldn't be too many times that type 4 would need to be used,
except as an optomization (change places where we make a STRING then
free the memory that the cstring was in, into making a STRING and giving
up ownership of the cstring-pointer to the STRING). As I recall, there
are places in perl5 where buffers are "stolen" instead of copied... this
would be the same sort of thing.
Strings whose buffers are of type 2 would have a big advantage with
respect to COW: nothing needs to be done to make them COW (we copy the
pointer, and copy the flags), and nothing needs to be done to make them
non-COW.
In addition, I think we need *another* argument: One to tell what type
of STRING* object we want back. In particular, we might want back a
constant one, for which appending or truncating is illegal. In addition
to that, we might (or might not) be willing to accept a STRING which
isn't newly allocated, but was cached from an earlier call.
> key = key_new_cstring(interpreter, "_message");
IMHO, key_new_cstring should allow a "flags" argument, so that we can
pass in either a PObj_external_FLAG or 0; otherwise, it won't know
whether or not it needs to make a copy.
> to create some STRINGs or entries in hashes. The keys should be constant
> PMCs and they should be shared as well as the STRINGs.
> We need this in objects.c ("\0\0anonymous"), for setting standard
> property names internally and for the current hash based implementation
> of Exceptions.
>
> This leads to my proposal:
> * const_string_from_cstring - return cached constant string or create
> one
Instead of a new entry point, how about adding whatever behavior you
want here to be an added behavior of string_from_cstring, dependent on
what flags were passed as a third argument?
> * const_key_new_cstring - return cached PMC or create a constant PMC
If
> * constant_pmc_new* - ditto (called from above)
>
> Further we would need for some classes a Const$Class variant, where the
> set-like vtables throw an exception. These classes should be
> autogenerated from *.pmc for all classes that have a "const_too" or such
> in their classes $flags.
>
> This leads to changes in parsing the vtable.tbl - which we need anyway
> to do the proposed var/value split of vtables.
>
> e.g.
> [FETCH]
> get_integer
> ...
> [STORE]
> set_integer
> ...
> [PUSH]
> push_integer
> ...
> and so on.
> The section names conform (where applicable) to methods described in
> Tie::*(3pm).
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
