memory management

memory management

[stefan]

Dear Guile'ers,

the manual from HEAD branch CVS tells me to use scm_malloc() instead of
scm_must_malloc() when allocating memory not connected to smobs.  There is
no scm_free():

 > The memory is allocated by the libc @code{malloc} function and can be
 > freed with @code{free}.  There is no @code{scm_free} function to go
 > with @code{scm_malloc} to make it easier to pass memory back and forth
 > between different modules.

Can you plese explain what "make it easier to pass memory back and forth
between different modules" means?  What are modules in this context?

Wouldn't it be more othogonal to supply a scm_free()?

The actual reason I ask for the implementation of a scm_free() is as
follows.  I am a developer of Serveez.  It uses Guile as configuration
language and also as implementation language for quite some time.  The
software is portable to Win32.  Thus we need Guile be portable to Win32.
Lots of the changes in Guile CVS regarding Win32 portability were made by
myself.  On Win32 systems there is not such a thing like a standard libc.
There are different APIs around, especially regarding memory management.
When you use e.g. gh_scm2newstr() from an application linked against
libguile.dll (which was ported using the msvcrt.dll - one of the libc's)
and the calling application is linked against another libc (e.g.
kernel32.dll only) which provides 'another' free() as the msvcrt.dll... it
fails!  This is bad I know, but not to work around...

Would you supply a scm_free() inside libguile.dll there would be no
problem, because then the free() called inside libguile.dll:scm_free()
would match the previous malloc() (also called inside libguile.dll).

In previous versions of Guile I helped myself calling scm_must_free()
which sufficed for this purpose perfectly.

Thanks in advance,
	stefan@lkcc.org

PS: Please CC answers to my private email, because I wouldn't read the
    guile-devel list too regularily.

PPS: I am waiting for the coop-thread thingie to have finsished in Guile
     devel to put the pending changes regarding Win32 portability into
     CVS...

Re: memory management

[Marius Vollmer]

stefan <stefan@lkcc.org> writes:

>  > The memory is allocated by the libc @code{malloc} function and can be
>  > freed with @code{free}.  There is no @code{scm_free} function to go
>  > with @code{scm_malloc} to make it easier to pass memory back and forth
>  > between different modules.
> 
> Can you plese explain what "make it easier to pass memory back and forth
> between different modules" means?  What are modules in this context?

`Modules' is meant to mean different, errm, 'code regimes', like
libraries from different projects or developers.  These different
bodies of code have not necessarily been specifically written to work
together, but supposedly, they all use libc for their basic memory
management.

> Wouldn't it be more othogonal to supply a scm_free()?

Yeah, but we would force people to always pair scm_malloc with
scm_free.  (Offering scm_free without forcing people to use it would
have no effect.)  When they can't use scm_free because they have no
control over the code doing the freeing, they consequently can't use
scm_malloc although it might have been the right thing.  By not
insisting on scm_free, we make scm_malloc more useful.

> [...] On Win32 systems there is not such a thing like a standard
> libc.  There are different APIs around, especially regarding memory
> management.  When you use e.g. gh_scm2newstr() from an application
> linked against libguile.dll (which was ported using the msvcrt.dll -
> one of the libc's) and the calling application is linked against
> another libc (e.g.  kernel32.dll only) which provides 'another'
> free() as the msvcrt.dll... it fails!  This is bad I know, but not
> to work around...

This sounds like a very fundamental problem and I frankly don't want
to be drawn into the maelstrom of trying to fix it.  Next thing you
know, you can't pass a FILE* around, either!

When you step back one level, you have the problem that memory
allocated with "malloc" can not be freed with "free" when the memory
crosses a 'libc border'.  The only real solution that I can see is not
to mix more than one libc into a single program.

> Would you supply a scm_free() inside libguile.dll there would be no
> problem, because then the free() called inside libguile.dll:scm_free()
> would match the previous malloc() (also called inside libguile.dll).

If you can instruct code to use libguile.dll:scm_free instead of
kernel32.dll:free, can't you also instruct it to use msvcrt.dll:free
instead of kernel32.dll:free?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

Re: [dev-serveez] Re: memory management

[stefan]

On 18 Mar 2003, Marius Vollmer wrote:

> > Would you supply a scm_free() inside libguile.dll there would be no
> > problem, because then the free() called inside libguile.dll:scm_free()
> > would match the previous malloc() (also called inside libguile.dll).
>
> If you can instruct code to use libguile.dll:scm_free instead of
> kernel32.dll:free, can't you also instruct it to use msvcrt.dll:free
> instead of kernel32.dll:free?

I would need to call libguile.dll:libc:free.  I would need to know to
which libc libguile.dll was linked.

BTW:  The standard libc for MinGW is 'msvcrt.dll'.  You get into trouble
      when you want to use another (native) compiler, like BorlandC or
      VisualC.

So what would be the correct solution without scm_free()?

Thanks in advance,
	stefan@lkcc.org



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Re: memory management

[Marius Vollmer]

stefan <stefan@lkcc.org> writes:

> I would need to call libguile.dll:libc:free.  I would need to know to
> which libc libguile.dll was linked.

I see.

> BTW:  The standard libc for MinGW is 'msvcrt.dll'.  You get into trouble
>       when you want to use another (native) compiler, like BorlandC or
>       VisualC.
> 
> So what would be the correct solution without scm_free()?

I can't say.  However, I really don't want to change the Guile API
because of (what appears to me as) an obscure fringe problem.

This does not mean that we wont cater to MinGW, patches to make Guile
run on any platform are highly welcome.  But I say it is wrong to
change the public API of Guile because of the weird possibility of
having two libcs in one address space.  The 'free' issue can only be
the tip of the iceberg: other libc or POSIX things such as stdio,
signals will probably cause problems as well, and the only real
solution that I can think of is: there shall be only one libc.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405