David Kastrup <d...@gnu.org> skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> David Kastrup <d...@gnu.org> skribis:
[...]
>>> It would not help since many of the references are stored in STL
>>> containers (like std::vector <Grob *>) which have their data
>>> allocated/deallocated separately from the memory area of the
>>> structure itself.
>>
>> Oh, OK. Still, I don’t think this is a problem because each C++
>> object has a corresponding SMOB, and said SMOB is GC-protected; thus
>> the C++ object itself is also GC-protected until the SMOB is
>> unprotected.
>
> The code given in test.cc is representative for LilyPond: most of the
> C++ objects refer to other C++ objects via pointers, and the protection
> of SMOB and C++ objects is managed through the mark callbacks. Complex
> C++ objects contain their own SCM value as part of the Smob base class.
> Simple C++ objects (derived from Simple_smob) don't and are only
> optionally managed by GUILE.
I don’t think this contradicts what I wrote above, does it?
>> Here’s the patch I’ve ended up with:
>>
>> diff --git a/smobs.hh b/smobs.hh
>> index 3701280..a41a645 100644
>> --- a/smobs.hh
>> +++ b/smobs.hh
>> @@ -263,6 +263,20 @@ private:
>> protected:
>> Smob () : self_scm_ (SCM_UNDEFINED), protection_cons_ (SCM_EOL) { };
>> public:
>> + static void *operator new (std::size_t size)
>> + {
>> + /* This C++ object is referred to by the corresponding SMOB, which is
>> + itself GC-protected. Thus, no need to protect the C++ object. */
>> + return scm_gc_malloc (size, "lily-smob");
>> + }
>> +
>> + static void operator delete (void *thing)
>> + {
>> + /* Nothing to do: the GC will reclaim memory for THING when it deems
>> + appropriate. */
>> + // printf ("delete %p\n", thing);
>> + }
>> +
>
> As I stated: this will not help with STL containers which are
> extensively used in pretty much every data structure of LilyPond.
Sorry, I don’t understand how it doesn’t help.
It would be a problem is ‘Smob’ objects could be copied, thus ending up
in non-GC-scanned storage, but IIUC they cannot be copied because their
copy constructor is private.
What am I missing?
At any rate, I don’t see any failure with the test program.
>> I think it would help to get everyone involved on both sides. Thus,
>> could you Cc: this bug report to the LilyPond developer list, or the
>> corresponding LilyPond bug report? This is really important to me.
>
> Shrug. I'll put a link to this bug report to a suitable LilyPond issue.
Thank you. Though I want other LilyPond developers to get involved, and
I’m afraid it would be easy for them to just ignore a side bug report.
It’s a vital task for LilyPond, it cannot be a one-person side-project
on the LilyPond side.
Thanks in advance,
Ludo’.
