"Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
On Tue, Jan 24, 2006 at 03:52:39PM -0000, Jonathan Worthington wrote:
"Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
>The trick is to keep references to registers in a way that notices
>when the register set is gone, or alternatively, that keeps the
>register set from going away. The latter is already achieved by the
>default LexPad implementation.
Looking at it, I kinda see where you're coming from, but just stashing
away
and ensuring a LexPad PMC gets marked for a long as the reference gets
marked is not enough, as a LexPad PMC doesn't control lifetime of a
context
structure, which is responsible for the registers. OTOH, taking a
closure
does keep the context and thus register frame in place, which is perhaps
what you meant and seems workable.
That's a clever idea, creating a closure, but closures can't achieve any
kind of weak reference. They never want to let go of their context. So
that's a non-starter.
<speaking in terms of making my project basically work for now>
Yes, though it gets freed when the closure PMC is no longer reachable. And
the point is that a managed pointer PMC pointing to a register *should*
always become unreachable by the end of the execution of the sub it was
created in. Though it did occur to me that my managed pointer PMC can
increment the context's ref count on creation, decrement it on destruction
and thus no need for the closure.
<speaking in terms of what's good for Parrot/my project in the long term>
No, it's not a good solution and nor is the "optimization" I suggested.
What I had in mind, was imitating whatever a closure does to hold onto a
context chain. I would detail that here except it's not on the top of my
brain except (1) the point is the imitation-rather-than-usage strategy,
and (2) it won't work anyway, also due to the need for a weak reference.
>Therefore, the representation of a safe pointer to a register would
>not, in fact, be a pointer to the register's storage in memory, but
>rather a weak reference (or, conceivably, a strong one? I doubt it)
>plus an integer register number.
A weak reference to the closure PMC, I assume?
Well, what I meant at the time was a weak reference to the context, so
when the context evaporates on its own, you can be notified. But since
contexts aren't actually GC-able yet that's pretty much impossible now.
To get what you want, you may have to introduce cheap-ass pseudo-GC
pseudo-weak-reference mechanism for contexts. For example, a list of
callbacks attached to contexts that are to be called when the context's
refcount hits zero.
I'd prefer to reuse something in the engine already for those callbacks.
If a lightweight callback mechanism, with parameter, doesn't already
exist, then you could either use a closure for -that- (eh, too expensive)
or else invent such a mechanism for general use, with yourself as first
customer.
There is a mechanism used to do this kinda thing for exit handlers
(src/exit.c), but it doesn't look particularly general. I guess leo will
know if there is something I've missed - leo, thoughts? I guess such a
mechanism probably shouldn't be much work to implement, though, and would
certainly be a nice, clean answer.
Ah, and the reference might not be to an integer register, but that's
just detail...
I imagined that the references would only ever be to -PMC- registers...?
I wouldn't have thought so. I thought in Perl 6 the lowercased types like
"int" were to go in the I registers. I think we'd still want to be able to
create a reference to them though. In the .NET case, there's no reason not
to use I registers for its integers. I guess they could all be PMCs, but
that'd be kinda expensive.
... the managed reference PMC will hold a reference to the array PMC
plus the element number (or object PMC and field name). Yes,
performance will not be amazing, but that ain't really the goal.
That's a good approach, as far as it goes. Given the amazing variety of
"array" PMCs you can't possibly guarantee that there will be a memory
address there to use, even without movement issues.
Yes, there's no external interface to get one.
But a .Net-specific solution seems unworthy. .Net translation isn't
nearly the only code that will want mutable pseudo-references to aggregate
elements. Seems to me that aggregates should have vtable methods to
create such, with the possibility of specializing. For example, a mutable
proxy object for %ENV{$foo} would not bother with hash manipulation; it
would just call getenv() and setenv().
In the long term, yes this would be very nice. In the short term, I've got
a project that comes complete with a deadline, so the I'm afraid the .Net
specific one will have to be the way it is for now. Not that it affects
Parrot really, or at least until my code goes public and people start
thinking it shows good ways to do stuff. :-)
Thanks,
Jonathan
