From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.network.serveez.devel,gmane.lisp.guile.devel Subject: Re: memory management Date: 18 Mar 2003 20:48:50 +0100 Sender: dev-serveez-bounces+gnu-dev-serveez=m.gmane.org@gnu.org Message-ID: <8765qgzc9p.fsf@zagadka.ping.de> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1048017009 24407 80.91.224.249 (18 Mar 2003 19:50:09 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 18 Mar 2003 19:50:09 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: dev-serveez-bounces+gnu-dev-serveez=m.gmane.org@gnu.org Tue Mar 18 20:49:58 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18vN5x-0006Jm-00 for ; Tue, 18 Mar 2003 20:49:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18vN5s-0006It-01 for gnu-dev-serveez@m.gmane.org; Tue, 18 Mar 2003 14:49:52 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18vN5A-0004kh-00 for dev-serveez@gnu.org; Tue, 18 Mar 2003 14:49:08 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18vN4x-0003yY-00 for dev-serveez@gnu.org; Tue, 18 Mar 2003 14:49:00 -0500 Original-Received: from mail.dokom.net ([195.253.8.218]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18vN4v-0003qs-00 for dev-serveez@gnu.org; Tue, 18 Mar 2003 14:48:53 -0500 Original-Received: from dialin.speedway43.dip97.dokom.de ([195.138.43.97] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 18vN5W-00076c-00 for dev-serveez@gnu.org; Tue, 18 Mar 2003 20:49:30 +0100 Original-Received: (qmail 9643 invoked by uid 1000); 18 Mar 2003 19:48:51 -0000 Original-To: stefan In-Reply-To: Original-Lines: 53 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Original-cc: Serveez Developer Mailing List X-BeenThere: dev-serveez@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for the GNU serveez List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: dev-serveez-bounces+gnu-dev-serveez=m.gmane.org@gnu.org Xref: main.gmane.org gmane.network.serveez.devel:104 gmane.lisp.guile.devel:2087 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2087 stefan 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