[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GC + Java finalization
From: |
Maxime Devos |
Subject: |
Re: GC + Java finalization |
Date: |
Fri, 19 Nov 2021 14:01:58 +0000 |
User-agent: |
Evolution 3.38.3-1 |
Jonas Hahnfeld schreef op vr 19-11-2021 om 14:53 [+0100]:
> [...]
> The straight-forward solution is to statically tie the lifetime of
> regex_t to that of the smob. Which we cannot do with GC, but simply
> with malloc+free - as implemented in the patch.
OK, but for clarity I recommend adding a comment like
/* When not using Java-style finalisation, we must make sure
the memory for the regex_t is only freed after regfree.
To do so, use scm_malloc+free instead of scm_gc_free such
that boehmgc will only free the regex_t when we ask it to
in regex_free, and it won't automatically free the regex_t
too early. */
Otherwise, it would be easy to think ‘Hmm, this code would be
simpler if we just use scm_gc_malloc and remove the unnecessary
free’ and accidentally introduce a bug ...
Greetings,
Maxime
- Re: GC + Java finalization, Jonas Hahnfeld, 2021/11/19
- Re: GC + Java finalization, Maxime Devos, 2021/11/19
- Re: GC + Java finalization, Jonas Hahnfeld, 2021/11/19
- Re: GC + Java finalization, Maxime Devos, 2021/11/19
- Re: GC + Java finalization, Jonas Hahnfeld, 2021/11/19
- Re: GC + Java finalization, Maxime Devos, 2021/11/19
- Re: GC + Java finalization, Maxime Devos, 2021/11/19
- Re: GC + Java finalization, Jonas Hahnfeld, 2021/11/19
- Re: GC + Java finalization,
Maxime Devos <=
- Re: GC + Java finalization, Maxime Devos, 2021/11/19
- Re: GC + Java finalization, Jonas Hahnfeld, 2021/11/19
- Re: GC + Java finalization, Maxime Devos, 2021/11/19
- Re: GC + Java finalization, Jonas Hahnfeld, 2021/11/19
- Re: GC + Java finalization, Maxime Devos, 2021/11/19
- Re: GC + Java finalization, Jonas Hahnfeld, 2021/11/19
Re: GC + Java finalization, Maxime Devos, 2021/11/19