Re[2]: [Gc] libatomic_ops: Latest commits

Ivan Maidanski ivmai at mail.ru
Thu Sep 10 15:34:58 PDT 2009


Hi!

"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.

Agreed here.

> 
> 5) Check in C++0x support, and any other pending patches.
>
> 6) Do the tree reorganization.
> 
> Does this sound right?
> 
> Hans

Bye.


More information about the Gc mailing list