[Top][All Lists]
[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 16:00:57 +0100 |
On Wed, 2011-05-11 at 15:54 +0200, R. Mattes wrote:
> On Wed, 11 May 2011 08:15:41 -0500, Jeremiah Benham wrote
> > >
> > > Jeremiah - do you have time to pick this up again, the tidying up of
> > > the
> > > memory leaks in view.c scheme stuff?
> >
> > Yes. I have some time to do that. I am a bit confused as to what I
> > need to do now. I'll read over this thread a few more times and ask
> > some questions perhaps.
>
> I think the general approach should be:
>
> * There _are_ situations where scm_dynwind-protection is needed.
> All calls
> into scheme while resources are temporarily allocated need to be protected
> by setting up a dynwind context _and registering all cleanups with that
> context_. [Note: very confusing: atm there are calls to scm_dynwind_end
> in functions that don't call scm_dynwind_begin. That's asking for trouble
> ...)
>
> * Functions that _don't_ call into scheme or that call scheme while there is
> no chance of non-local exits should clean up their locally allocated
> resources
> themself.
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. Instead free any C
strings created with scm_to_locale_string() using free() (not g_free()).
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. 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 :(
It is only not crashing at the moment, because it seems scheme is not
collecting its garbage...
Richard
>
> BTW, just a comment on style: while a macro like SCM2LSTRING seems like a good
> idea
> to save a few keystrokes it's very tempting to write something like:
>
> scm_dynwind_begin();
> char* my_string = SCM2LSTRING(a_scn_val);
> ....
>
> scm_dynwind_end();
>
> ...
>
> char* foo = my_string;
>
>
> More questions?
>
> Cheers, RalfD
>
>
> --
> R. Mattes -
> Hochschule fuer Musik Freiburg
> address@hidden
>
- Re: [Denemo-devel] Midi shortcuts, (continued)
- Re: [Denemo-devel] Midi shortcuts, Richard Shann, 2011/05/10
- Re: [Denemo-devel] Midi shortcuts, Richard Shann, 2011/05/10
- Re: [Denemo-devel] Midi shortcuts, R. Mattes, 2011/05/10
- Re: [Denemo-devel] Midi shortcuts, Richard Shann, 2011/05/11
- Re: [Denemo-devel] Midi shortcuts, R. Mattes, 2011/05/11
- Re: [Denemo-devel] Midi shortcuts, Richard Shann, 2011/05/11
- Re: [Denemo-devel] Midi shortcuts, Jeremiah Benham, 2011/05/11
- [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts, R. Mattes, 2011/05/11
- Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts,
Richard Shann <=
- Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts, R. Mattes, 2011/05/11
- Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts, Richard Shann, 2011/05/11
- Re: [Denemo-devel] scm_dynwinds etc. [was:] Midi shortcuts, R. Mattes, 2011/05/11
- [Denemo-devel] Patchset: denemo-specific guile load path, R. Mattes, 2011/05/14
- Re: [Denemo-devel] Patchset: denemo-specific guile load path, Richard Shann, 2011/05/15
- Re: [Denemo-devel] Patchset: denemo-specific guile load path, R. Mattes, 2011/05/15
- Re: [Denemo-devel] Patchset: denemo-specific guile load path, Richard Shann, 2011/05/15
- Re: [Denemo-devel] Patchset: denemo-specific guile load path, Richard Shann, 2011/05/17
- Re: [Denemo-devel] Patchset: denemo-specific guile load path, Richard Shann, 2011/05/18
- Re: [Denemo-devel] Midi shortcuts, Nils Gey, 2011/05/07