Branch updates

Reini Urban rurban at x-ray.at
Fri Jan 4 23:22:05 UTC 2013


On Fri, Jan 4, 2013 at 5:17 PM, Reini Urban <rurban at x-ray.at> wrote:
> On Thu, Jan 3, 2013 at 12:23 AM, Jonathan "Duke" Leto <jonathan at leto.net> wrote:
>> I don't see any recent updates to api.yaml, is there anything from your
>> recent branch merges that should be listed there?
>
> Thanksfully nothing.

Spoke too early.
I added this new entry in docs/deprecations/deprecations.pod

Changes Between 4.9 and 4.12

Moved "." in the library search paths from the beginning to the end.

- low impact expected:
  load_bytecode and .include and load_language might load now different files,
  if they exist in "./" AND in the proper library location.
  To keep the old behavior set the environment variables PARROT_INCLUDE
  and PARROT_LIBRARY to "./"

I believe PARROT_DYNEXT and dynext_dirs need to be added to api.yaml

>>> rurban/pcre-dynext_libs-gh302
>>>   new dynext_dirs config entry, new ENV var PARROT_DYNEXT, new
>>> add_env_paths()
>>>   test in lib_search_path.t
>>
>> It doesn't look like the new environment variables have any user-visible
>> documentation. I would prefer to defer merging until we have new some
>> documentation with examples of why and how our users would want to use
>> PARROT_DYNEXT.
>
> oops, already merged.
> I'll add some docs instead.
>
>>> !!! rurban/fix-gc-thr-gh880+gh875
>>>   GC should stop walking into another thread interp.
>>>   Someone should help me with this blocker. I also get work_list asserts,
>>>   and there's not even a threaded GC stress test yet.
>>>   Easy to repro: parrot -t7 and some threaded code.
>>
>> Can you submit an issue with the simplest threaded code that exhibits this
>> bug when run with -t7 ? Also, if you have time, if you can create an issue
>> with a specification for what a threaded GS stress test should do, we might
>> be able to get you some help with that.
>
> I added stress tests to the branch rurban/fix-gc-thr-gh880+gh875
> where I try various attempts.
>
>> I agree that this is an important issue that I would really like to see
>> solved before 5.0.0 if possible. If you can braindump as much as you can
>> into a github issue, that would be helpful.
>
> See the two issues involved 880 and 875, but it really just one error.
> I thought this little snippet fixed it, but apparently not:
>
>     Also block the sweep phase from proxied interps. Previously only the mark.
>
> diff --git a/src/pmc/parrotinterpreter.pmc b/src/pmc/parrotinterpreter.pmc
> index 3d1ffa7..06c8e5e 100644
> --- a/src/pmc/parrotinterpreter.pmc
> +++ b/src/pmc/parrotinterpreter.pmc
> @@ -840,11 +840,13 @@ Schedules the given task on the proxy's interpreter.
>          /* don't run GC from the wrong thread since GC involves stack
> walking and we
>           * don't want the foreign GC to find our objects */
>          Parrot_block_GC_mark_locked(proxied_interp);
> +        Parrot_block_GC_sweep(proxied_interp);
>
>          Parrot_cx_schedule_immediate(proxied_interp,
>              Parrot_thread_create_local_task(INTERP, proxied_interp, task));
>
>          Parrot_unblock_GC_mark_locked(proxied_interp);
> +        Parrot_unblock_GC_sweep(proxied_interp);
>  #else
>          Parrot_cx_schedule_immediate(interp, task);
>  #endif
>
>
>
> --
> Reini Urban
> http://cpanel.net/   http://www.perl-compiler.org/



-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/


More information about the parrot-dev mailing list