Re: [Gc] libatomic_ops: Latest commits
ivmai at mail.ru
Thu Sep 10 15:34:58 PDT 2009
"Boehm, Hans" <hans.boehm at hp.com> wrote:
> Great! Thanks!
> I looked at the patches quickly, and they seem fine to me, as usual. With Ivan checking things in directly, we will hopefully at least come a lot closer to getting caught up.
> I know that one of the many pending patches is one that restructures the directory organization.
This one? - http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/2484/match=msvc_dbg
- I guess, the patch is still valid (in fact, this is critical for me to have these "extra" .c files is another directory (otherwise it complicates my internal building scripts) and I think this directory reorganization could break anything since such files as threadlib.c are intended to be used from the build scripts only).
> And I have been holding off on a patch to support the C++0x GC API, which I think is important, but would add instability.
I'm sure this could be ifdef'ed but requires time and efforts...
> I think we should aim for an approach like:
There could be one more step:
0) change libatomic_ops version (to next alpha) and release a standalone tar-ball for it (and change the version again for cvs to avoid confusion).
> 1) Check in any other bug fix patches, or patches that enhance portability at
> small risk to working platforms. Check in "make dist" patches.
I'd like also here repost (and hopefully check in if no objections) a dozen of my old patches (some of which pending from last year) and also post a patch for WinCE (enabling parallel marking w/o pthreads) - that's a matter of 2-3 days (to resubmit them for the audience).
Among the patches:
- more "solid" (and public) support for "do blocking" (and "unblocking");
- "default" stop function;
- correct use of oom_func in register_dlink/finalizer;
- reporting (when logging) finalization short statistics on every collect;
- misc issues (like compiler warnings suppression).
Also, I think it would be good if the GCJ folks could suggest patches for seamless GC integration.
> 2) Put out a 7.2alpha4 for testing. (Note that alpha<n>, n odd, is currently reserved for unreleased cvs versions, to avoid confusion.
> 3) Any needed bug fixes.
> 4) Make available 7.2.
> 5) Check in C++0x support, and any other pending patches.
> 6) Do the tree reorganization.
> Does this sound right?
More information about the Gc