[Gc] Re[5]: GC_is_disabled returns false when GC_enable() is called too many times

Ivan Maidanski ivmai at mail.ru
Sun Dec 9 11:49:51 PST 2012


Hi Kjetil,

I see your reason.
But our current API guarantees (and GC relies on this fact internally) that GC_disable always disables any GC activity (unlike GC_enable which only enables GC in case it is not nested).
I've added an assertion for the underflow in GC_enable - https://github.com/ivmai/bdwgc/compare/72092ed8de...4c95005

9 Dec 2012, 16:42 Kjetil Matheussen <k.s.matheussen at notam02.no>:
>Hi Ivan,
>
>
Let's say the default behavior in a program is to disable the GC.
>
Then you might have functions looking like this:
>
>
{
>
   GC_enable();
>
   <do something>
>
   GC_disable();
>
}
>
>
And in case <do something> calls a function which calls GC_enable() 
>
another time,
>
the garbage collector will be disabled (!), since GC_dont_gc then gets 
>
the value -1.
Now I fixed this, the collector will not be disabled, abort will be fired instead.
This is, of course, not what you want but matches the specification.


But you could use your own counter in the application and own enable/disable that increments/decrements the counter calling GC_enable/disable on crossing zero.

Regards,
Ivan

>
>
>
>
On 09.12.2012 15:51, Ivan Maidanski wrote:
>
> Hi Kjetil,
>
>
>
> According to the current design, GC_disable/enable usage is as:
>
>
>
> GC_disable();
>
> /// do something critical
>
> GC_enable();
>
>
>
> Thus unbalanced disable/enable should be a client bug.
>
>
>
> What are you reason to request a change?
>
>
>
> Regards,
>
> Ivan
>
>
>
> 9 Dec 2012, 14:55 Kjetil Matheussen :
>
>
>
>> On 09.12.2012 14:24, Kjetil Matheussen wrote:
>
>> > On 09.12.2012 14:21, Kjetil Matheussen wrote:
>
>> >> ...which is quite confusing. Perhaps GC_is_disabled should be
>
>> >> changed
>
>> >> like this?
>
>> >>
>
>> >>
>
>> >> [kjetil at ttlush gc-7.2]$ diff -u misc_bu.c misc.c
>
>> >> --- misc_bu.c 2012-12-09 14:18:53.185065422 +0100
>
>> >> +++ misc.c 2012-12-09 14:20:33.955746560 +0100
>
>> >> @@ -1472,7 +1472,7 @@
>
>> >>
>
>> >> GC_API int GC_CALL GC_is_disabled(void)
>
>> >> {
>
>> >> - return GC_dont_gc != 0;
>
>> >> + return GC_dont_gc >= 0;
>
>> >> }
>
>> >>
>
>> >> /* Helper procedures for new kind creation. */
>
>> >
>
>> >
>
>> > Ouch. I ment:
>
>> >
>
>> >
>
>> > [kjetil at ttlush gc-7.2]$ diff -u misc_bu.c misc.c
>
>> > --- misc_bu.c 2012-12-09 14:18:53.185065422 +0100
>
>> > +++ misc.c 2012-12-09 14:23:55.108103240 +0100
>
>> > @@ -1472,7 +1472,7 @@
>
>> >
>
>> > GC_API int GC_CALL GC_is_disabled(void)
>
>> > {
>
>> > - return GC_dont_gc != 0;
>
>> > + return GC_dont_gc > 0;
>
>> > }
>
>> >
>
>> > /* Helper procedures for new kind creation. */
>
>> >
>
>>
>
>> Hmm, I see now that the current behaviour is
>
>> correct according to documentation, and that this would
>
>> be an API change. Sorry for the noise.
>
>>
>
>> Perhaps the API for enable/disable should be changed in the next
>
>> major version?
>
>>
>
>> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20121209/1faaf42f/attachment.htm


More information about the Gc mailing list