On Tue, 2011-05-10 at 23:39 +0200, R. Mattes wrote: > On Tue, 10 May 2011 18:33:42 +0100, Richard Shann wrote > > On Sun, 2011-05-08 at 11:39 +0200, R. Mattes wrote: > > > BTW, my code example is longer than it needs to be, there's no > need > > > to establish a dynamic context at all - I was fooled by the > original > > > code. No idea why there's scm_dynwind_... at all. No need for it. > > > > Jeremiah - Ralf is confirming my suspicions here - I think we should > > simply be calling g_free() on the strings that we have created on > the > > heap. > > Yes. Guile won't free any memory you allocate in C. > > > I am not sure what scm_dynwind_... is for, if it is doing anything > > it is only saving us the effort of writing those g_free() calls > > before returning. > > It won't. Dynamic (un)winding has a different purpose. In a situation > like the following: > > a_thing = alloc_new_thing(); > > scm_eval_string(); <------- [1] > > free_thing(a_thing); <----- [2] > > > The call in [1] transfers control to scheme. Now, in Scheme function > calls might never return since it's always possible to do non-local > exits > (for example by call-with-current-continuation). So it's not > guaranteed > that [2] is ever reached. This might leak memory. > Now scm_dynwind_ sets up an unwinding context. This is only a setup, > you still > need to register cleanup functions with that context. Now whenever > scheme > leaves this dynamic context by means of a non-local exit these > cleanup > function are called (Richard, since you seem to have some Lisp > bakground: > this is the C equivalent of Common Lisp's unwind-protect). > So, setting up a dynamic context without registering some sort f > cleanup > with it ( scm_dynwind_unwind_handler(a_thing) in my example) simply > does > nothing (Hint: Guile has a very fine manual - Section 'Dynamic > Winds').
Well, I found your explanation much clearer :) Thanks a lot for this - it is the longjmp thing that I wasn't really taking on board. Incidentally the Lisp I did was pretty simple stuff IIRC, something to do with content-addressable image databases, nearly 20 years ago now... Jeremiah - do you have time to pick this up again, the tidying up of the memory leaks in view.c scheme stuff? There is clearly a completely separate problem, I presume a memory leak in lilydirectives.c where just enquiring about a non-existent directive gobbles memory. I'll look into that. Richard _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
