threads blocker: Not so transparent proxies

[Stefan Seifert]

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