On Wednesday 21 November 2012 10:26:28 Reini Urban wrote:
> nqplexinfo, the NQP lexpad for $a which holds $x, might get created in
> another thread,
> and then the proxy returned by GET_ATTR_lexinfo(INTERP, SELF, info) in
> Parrot_NQPLexPad_set_pointer
> cannot handle the GETATTR_NQPLexInfo_name_to_register_map call.
Proxy proxies all VTable calls but the same might not be true fro the
GETATTR_* macros. I don't have nqp at hand, but a quick look at the parrot
sources tells me, that these macros usually either access the PMCs attributes
directly, or use a VTable call in case the PMC "is an object". I don't know
exactly what the latter means, but this could be a way to proxy GETATTR_*
calls without having to change every caller. Having the caller check would
lead to a slowdown after all.
Please also note that I have always expected the HLL compiler to show some
intelligence handling threads. E.g. the compiler would transfer something
like:
my $a = 1;
async {
say $a;
}
into:
.sub 'main' :main
.local PMC a, async_task, async_code
a = 1
async_task = new ['Task']
async_code = get_global 'async1'
setattribute async_task, 'code', async_code
push async_task, a
schedule async_task
.sub 'async1'
.local PMC interp, task, a
interp = getinterp
task = interp.'current_task'()
a = pop task
say a
Unfortunately I know almost nothing about how Rakudo or NQP are actually
implemented on Parrot...
Stefan
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
