On Fri, Jan 4, 2013 at 5:17 PM, Reini Urban <rur...@x-ray.at> wrote: > On Thu, Jan 3, 2013 at 12:23 AM, Jonathan "Duke" Leto <jonat...@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/ _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
