On Thu, Nov 24, 2005 at 08:54:54AM +0100, Leopold Toetsch wrote:
> On Nov 23, 2005, at 19:08, Chip Salzenberg wrote:
> >You keep confusing static and dynamic call information.
>
> While at static objects like subroutine PMCs - there is some code
> around that is setting properties on .Sub objects.
Just to be clear, I don't think setting properties on a Sub is
necessarily a bad thing. Let's say a user wants to create a bunch of
Subs and then set properties on them for some design reason, say for
the purpose of categorization or debugging or some such. That's fine
with me. I'm only concerned (at the moment :-)) about Parrot itself
storing dynamic (call-stack-dependent) state inside Sub objects.
BTW, this principle still applies to Closures, but in a non-obvious
way. Once Closures are cloned they can be called recursively, so call
stack info about _them_ being called still can't be stored in them.
Granted, they have attributes like "outer_ctx" (now) or "lex_env"
(someday). But those are actually metadata relating to the single
moment of the creation of the Closure: once the Closure is created,
they never change. So they're still really const attributes.
> $ find . -name '*.imc' -o -name '*.pir' | xargs grep -w setprop
Whole bunch of 'em, yup.
> At least one in runtime/parrot/library/Stream/Writer.imc is bogus if
> not illegal:
>
> .const .Sub stub = "_reader_stub"
> setprop stub, "CALL", source
>
That is surely a bug. It's non-reentrant at the very least.
I'd have to learn more about the Stream library to suggest a good fix.
A lame fix might be a static Hash that uses something stream-specific
as a key and the "CALL" attribute that would otherwise have been set on
those Subs as a value. Or maybe a property on the stream? (I'm just
guessing that there is such a thing as a stream PMC.)
> See also src/packfile.c:3200 and :377. The latter ('mark_1_seg') is run
> from GC to keep PMC 'constants' alive and I really don't like this. If
> PMC constants are created in the constant PMC pool, DOD-marking isn't
> needed anymore.
(Those line numbers don't match any more btw - if you want to write more
about it please update them)
The comment on mark_1_seg says that manually marking const PMCs is a
consequence of non-const-created properties. I think that's valid.
Granted, I don't like the idea of
3.14159 but hexagonal # [*]
and I hope nobody writes that. But the case of adding new properties to
compiled Subs seems valid.
[*] Old joke about Illinois (?) legislator who attempted to declare
that, officially, pi == 3. Consequences to all circles in the
state should be obvious. :-,
--
Chip Salzenberg <[EMAIL PROTECTED]>
