Re: [Gc] My old suggested minor changes
ivmai at mail.ru
Tue Nov 11 02:36:39 PST 2008
"Boehm, Hans" <hans.boehm at hp.com> wrote:
> I was actually just looking at this last Friday. I'm not very happy with the way the "retrieve only" flag is currently being passed into the setter functions. Passing ~0 as an unsigned argument seems ugly. Passing (some_fn*)(-1) seems worse. And currently the function setters are not consistent, since GC_set_oom_fn recognizes a zero argument.
Even more, "(func_t)-1" produces a warning on targets where sizeof(func_t)!=sizeof(int).
There are to kinds of global R/W vars: of int/word type and of func ptr type.
My initial intention was to import only funcs from a DLL (not global vars). Later I've noticed that -1 is an invalid value for all setters of non-func type (and (func_t)0 value is invalid for setters of func type (except for GC_set_finalizer_notifier()), so I've added a "getter" functionality for these setters using corresponding "invalid" values. May be, it would be more graceful to have a stand-alone getter for every setter function, but, in practice, the global vars we are talking about are really for setting only (IMHO). But, note, if we are thinking about strict backward compatibility, GC v6 already has one setter function (GC_set_free_space_divisor()) returning the old value.
> It would be marginally better to define macros for each of these special arguments. But I think that's ugly too, since there would be too many different ones. I don't know of a way to make this interface consistent and sufficiently memorable that it's not error-prone.
I don't think C programmers would suffer much from a lack of such macros (but, anyhow, it should cleanly documented).
> The more I think about this, the more I'd be inclined to just split the getter and setter functionality, with void returning setters. I think it's much cleaner. Currently none of these acquire a lock. Thus there is no real advantage to doing both in a single call. They at best provide a false illusion of atomicity.
To not provide such illusion, lock-free behavior should be explicitly doc'ed. Also it should be pointed out that these funcs could be (or should be for GC_set_no_dls()) called before GC_INIT().
> I'll apply this patch for now, since it clearly gets us to a better state. But I think it's moving us away from the global optimum, and we really want to do something else.
I agree it's not ideal (and, may be, it should be changed somehow), but these things are not of much importance. More important that you are stuck to compatibility issues in the future having released a non-alpha version of the library.
More information about the Gc