Branch updates

[Reini Urban]

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.

>> 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/