denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts


From: Richard Shann
Subject: Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts
Date: Wed, 11 May 2011 17:30:24 +0100

On Wed, 2011-05-11 at 17:59 +0200, R. Mattes wrote:
> On Wed, 11 May 2011 16:00:57 +0100, Richard Shann wrote
> > In practice this just means removing all the scm_dynwind stuff that you
> > did, as we don't do any non-local jumps from scheme. 
> 
> Here I disagree - you cannot predict what user-provided scheme code
> might do. And scheme code might always throw an uncought
> exception. This would lead to leaking memory.
I have been trying to get my head round this - before I wrote that I
checked what we are doing (I know, I wrote it, but that doesn't mean
anything):
 Any user script is being run with our error handler standard_handler()
in view.c, and after that finishes, control returns to the C code (in
activate_script() in view.c).
But the code with all the scm_to_locale_string() things is not calling
out to scheme, it is being called by scheme. So I think what I said
applies, we just need to free all the strings we create. I am assuming
that scheme will free the return SCM structure, if appropriate, from our
primitive procedures implemented in C (ie those things starting
scheme_xxx that are registered with scn_c_define_gsubr... calls). (That
is if I return a SCM_BOOL_T it presumably does not need to free anything
but if I return a SCM that is a string I presume it assumes that the C
code has not retained any reference to it).

> 
> > Instead free 
> > any C strings created with scm_to_locale_string() using free() (not 
> > g_free()).
> 
> Yes, even so g_free might be just a call to free, on some platforms memory
> must be freed by the same allocator library as the one that created it.
right - I checked that g_free() is not calling free() on my system.

>  
> >  More importantly the scm_take_from... need to revert to scm_from... 
> > in all cases. In the cases where the string being passed is freshly 
> > allocated (ie g_malloc'd) then call g_free() on it having created 
> > the scm_from... SCM structure.
> 
> And dont' forget to register it with the dynamic context! ;-)

it = the return SCM??? see above - do we need to do something to say
that the SCM returned by our C primitive procedure (gsubr...) should be
freed?

>  
> > We can't exploit scm_take_from... (as 
> > I previously suggested) because it calls free() and glib  is using 
> > its own memory allocator (so g_free() doesn't call free()). (So, 
> > another wild goose chase started by me I'm afraid :(
> 
> Ah, good to know. Anyway, looking at scm_take_from... in Guile 2 there will
> be no benefit performance-wise anyway. 
>  
> > It is only not crashing at the moment, because it seems scheme is not
> > collecting its garbage...
> 
> Have you tested with manual gc?
No, I'm afraid I haven't done any coding for a couple of days, but I
have realized as a result of all this that my treatment of the Undo
stack in the case of a script throwing an error is unnecessarily
elaborate, and I was just going to remove that and to deactivate the
scm_take_ calls because someone could potentially download the source
and compile on a system where guile would garbage collect with
disastrous results.

Richard


> 
>  Cheers, RalfD
>  
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]