Some notes: Instead of the interface sketched in the first message, consider an interface where the operations on leases that aren't specific to the type of the array being leased --- getting a lease on an object, freeing a lease, duplicating a lease, querying a lease --- are all independent of the type of the array being leased, and then having one function per element type that takes a lease and actually hands you the typed pointer. From owner-guile@cygnus.com Mon Jan 11 17:00:06 1999 Received: (from majordom@localhost) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) id IAA28478; Mon, 11 Jan 1999 08:03:39 -0800 (PST) Received: from totoro.red-bean.com (totoro.red-bean.com [209.43.2.137]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA28469 for ; Mon, 11 Jan 1999 08:03:36 -0800 (PST) Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id LAA26291; Mon, 11 Jan 1999 11:03:22 -0500 To: clark.mcgrew@sunysb.edu Cc: mdj@nada.kth.se, guile@cygnus.com, guile-numerical@nis.lanl.gov Subject: Re: gh_scm2doubles and friends References: From: Jim Blandy Date: 11 Jan 1999 11:03:21 -0500 In-Reply-To: Clark McGrew's message of Fri, 8 Jan 1999 03:08:00 +0900 (JST) Message-ID: Lines: 77 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-guile@cygnus.com Precedence: bulk Isn't the numeric group also talking about these issues? When converting a Scheme vector to a C vector of doubles, it's important in some applications to not to copy any more than necessary. When operating on uniform vectors of doubles, no copying is needed at all; C code should be able to get a reference to the body of the vector. That reference needs to be traced somehow, so that Guile's GC knows not to free the vector. One approach would be for Guile to hand out a "lease" to a vector's contents. Something like this: double *gh_lease_doubles (SCM VECTOR, gh_lease *LEASE); Convert the Scheme vector VECTOR to a C array of doubles, and return a pointer to that array. The returned array may or may not share memory with VECTOR. Modifications to the returned array within the proper range of indices will have undefined (but safe) effects on the contents of VECTOR. This function sets *LEASE to a 'lease' for the returned array. The caller is responsible for passing *LEASE to 'gh_free_lease' when it is done using the returned array. If the returned array shares memory with VECTOR, then VECTOR will not be garbage collected until this call; if the returned array is a copy, then this call will free its storage. SCM gh_unlease_doubles (gh_lease LEASE) Convert the array returned by the function which returned LEASE into a Scheme vector of the appropriate type. The returned object may or may not be identical to the one passed to the original function. void gh_free_lease (gh_lease LEASE) Free a lease on a possibly copied object. LEASE must be a lease object returned by some 'gh_lease_' function, which returned either a copy of or a reference to a Scheme object. If it returned a copy, this function will free it. If it returned a reference, the Scheme object is protected from garbage collection until this function is called. void gh_lease_shared (gh_lease LEASE) Return true iff the function that returned LEASE shared space with the original Scheme object. We could use a similar strategy to handle string contents. However, I think gh should still provide straightforward copying functions, for code that doesn't want to deal with the complexity, and can afford a copy. I think the typechecking is cleaner if leases are a separate object from the returned array, but if you don't mind casting pointers to integral types, then we could use the array itself as the lease identifier, and store it in a hash table. Then you wouldn't have lease objects flying around. The example code becomes: SCM example (SCM myvect) { gh_lease lease; double *mem; mem = gh_lease_doubles (myvect, &lease); some_function (mem, gh_length (myvect)); return gh_unlease_doubles (lease); } This will copy myvect only when sharing is not possible (i.e., it's actually a non-uniform vector, or a vector of integers, etc.). Does this sound appropriate? From owner-guile@cygnus.com Mon Jan 11 19:22:35 1999 Received: (from majordom@localhost) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) id OAA02650; Mon, 11 Jan 1999 14:49:22 -0800 (PST) Received: from boxer.physics.sunysb.edu (boxer.physics.sunysb.edu [129.49.30.187]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA02646 for ; Mon, 11 Jan 1999 14:49:19 -0800 (PST) Received: by boxer.physics.sunysb.edu via sendmail from stdin id (Debian Smail3.2.0.102) for guile@cygnus.com; Tue, 12 Jan 1999 07:47:17 +0900 (JST) Message-Id: Date: Tue, 12 Jan 1999 07:47:17 +0900 (JST) From: Clark McGrew To: mdj@nada.kth.se CC: jimb@red-bean.com, clark.mcgrew@ccmail.sunysb.edu, guile@cygnus.com, guile-numerical@nis.lanl.gov, mdj@nada.kth.se In-reply-to: (message from Mikael Djurfeldt on Mon, 11 Jan 1999 18:01:34 +0100) Subject: Re: gh_scm2doubles and friends Reply-to: clark.mcgrew@sunysb.edu References: Sender: owner-guile@cygnus.com Precedence: bulk >>>>> "Mikael" == Mikael Djurfeldt writes: Mikael> I think this is beautiful! That's the truth >>>>> Jim Blandy writes: >> SCM gh_unlease_doubles (gh_lease LEASE) Mikael> BTW, there's the question whether gh_unlease_doubles will Mikael> return a scm_tc7_dvect or a scm_tc7_vector. Mikael> One solution is that unlease returns the same type as the Mikael> original vector (the one which was leased). I like this suggestion. That way, it could also return fvect, or even some other type of vector. Also, since the lease will contain information about the type of array, and the type of object it might be possible to just have "gh_unlease" instead of gh_unlease_double, gh_unlease_long, &c. Cheers, Clark From owner-guile@cygnus.com Tue Jan 12 16:21:18 1999 Received: (from majordom@localhost) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) id KAA05352; Tue, 12 Jan 1999 10:51:41 -0800 (PST) Received: from totoro.red-bean.com (totoro.red-bean.com [209.43.2.137]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA05348 for ; Tue, 12 Jan 1999 10:51:38 -0800 (PST) Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id NAA27821; Tue, 12 Jan 1999 13:51:26 -0500 To: Mikael Djurfeldt Cc: guile@cygnus.com, guile-numerical@nis.lanl.gov Subject: Re: gh_scm2doubles and friends References: From: Jim Blandy Date: 12 Jan 1999 13:51:25 -0500 In-Reply-To: Mikael Djurfeldt's message of 11 Jan 1999 18:01:34 +0100 Message-ID: Lines: 30 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-guile@cygnus.com Precedence: bulk > Jim Blandy writes: > > > SCM gh_unlease_doubles (gh_lease LEASE) > > > > Convert the array returned by the function which returned LEASE > > into a Scheme vector of the appropriate type. The returned object > > may or may not be identical to the one passed to the original > > function. > > But we should add that gh_unlease_doubles also frees the LEASE. Yes, that's right. > BTW, there's the question whether gh_unlease_doubles will return a > scm_tc7_dvect or a scm_tc7_vector. > > One solution is that unlease returns the same type as the original > vector (the one which was leased). > > Maybe this was what you meant? I'm not sure. I like the idea of the lease remembering the type of the leased vector, and having that be the default behavior, but I imagine it would be useful to specify the return type, and have the copy take place only if a) the leased C array shares space with the leased vector, and b) the requested return type is different from that of the leased vector. Note that, if gh_lease_doubles made a copy of the vector, you don't need to do a second copy to turn it into a uniform vector of doubles. From owner-guile@cygnus.com Fri Jan 15 18:29:41 1999 Received: (from majordom@localhost) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) id PAA23485; Fri, 15 Jan 1999 15:14:49 -0800 (PST) Received: from lilly.ping.de (lilly.ping.de [195.37.120.2]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with SMTP id PAA23476 for ; Fri, 15 Jan 1999 15:14:45 -0800 (PST) Received: (qmail 25997 invoked by uid 10); 15 Jan 1999 23:14:23 -0000 Received: from zagadka.ping.de by lilly.ping.de with UUCP (rmail-0.1-fdc); 15 Jan 1999 23:14:23 -0000 Received: (qmail 8617 invoked by uid 1000); 15 Jan 1999 20:38:30 -0000 To: Jim Blandy Cc: clark.mcgrew@sunysb.edu, mdj@nada.kth.se, guile@cygnus.com, guile-numerical@nis.lanl.gov Subject: Re: gh_scm2doubles and friends References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: Marius Vollmer Date: 15 Jan 1999 21:38:30 +0100 In-Reply-To: Jim Blandy's message of "11 Jan 1999 11:03:21 -0500" Message-ID: <87d84gp8zd.fsf@zagadka.ping.de> Lines: 21 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-guile@cygnus.com Precedence: bulk Jim Blandy writes: > Does this sound appropriate? I like this. But I have developed a habit lately: whenever I see a pair of create/free functions I immediatly lobby for adding reference counting (at least) to the interface. Sooner or later you need to get serious about resource management among not-closely cooperating code and refcounting is the least intrusive step to take, I think. This refcounting could be added on top of the gh_lease functions, but I think it is better to provide it right from the start so that everyone knows how to coordinate with other code. So, what about adding gh_ref_lease and replacing gh_free_lease with gh_unref_lease? Or, for extra sillines, naming the functions gh_inclease and gh_declease? - Marius -- Go Meta! From owner-guile@cygnus.com Tue Jan 19 17:25:41 1999 Received: (from majordom@localhost) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) id MAA26916; Tue, 19 Jan 1999 12:01:28 -0800 (PST) Received: from totoro.red-bean.com (totoro.red-bean.com [209.43.2.137]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA26910 for ; Tue, 19 Jan 1999 12:01:24 -0800 (PST) Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id PAA08508; Tue, 19 Jan 1999 15:00:47 -0500 To: Marius Vollmer Cc: clark.mcgrew@sunysb.edu, mdj@nada.kth.se, guile@cygnus.com, guile-numerical@nis.lanl.gov Subject: Re: gh_scm2doubles and friends References: <87d84gp8zd.fsf@zagadka.ping.de> From: Jim Blandy Date: 19 Jan 1999 15:00:47 -0500 In-Reply-To: Marius Vollmer's message of 15 Jan 1999 21:38:30 +0100 Message-ID: Lines: 12 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-guile@cygnus.com Precedence: bulk > > Does this sound appropriate? > > I like this. But I have developed a habit lately: whenever I see a > pair of create/free functions I immediatly lobby for adding reference > counting (at least) to the interface. Eeeewwwww. Actually, would it suffice to just take out another lease on the object? We certainly have to support multiple leases of the same object anyway. From owner-guile@cygnus.com Wed Jan 20 16:53:21 1999 Received: (from majordom@localhost) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) id LAA15390; Wed, 20 Jan 1999 11:30:10 -0800 (PST) Received: from lilly.ping.de (lilly.ping.de [195.37.120.2]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with SMTP id LAA15384 for ; Wed, 20 Jan 1999 11:30:07 -0800 (PST) Received: (qmail 7874 invoked by uid 10); 20 Jan 1999 19:29:57 -0000 Received: from zagadka.ping.de by lilly.ping.de with UUCP (rmail-0.1-fdc); 20 Jan 1999 19:29:57 -0000 Received: (qmail 3012 invoked by uid 1000); 19 Jan 1999 23:21:24 -0000 To: guile@cygnus.com, guile-numerical@nis.lanl.gov Subject: Re: gh_scm2doubles and friends References: <87d84gp8zd.fsf@zagadka.ping.de> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: Marius Vollmer Date: 20 Jan 1999 00:21:24 +0100 In-Reply-To: Jim Blandy's message of "19 Jan 1999 15:00:47 -0500" Message-ID: <87pv8argqz.fsf@zagadka.ping.de> Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-guile@cygnus.com Precedence: bulk Jim Blandy writes: > > > Does this sound appropriate? > > > > I like this. But I have developed a habit lately: whenever I see a > > pair of create/free functions I immediatly lobby for adding reference > > counting (at least) to the interface. > > Eeeewwwww. > > Actually, would it suffice to just take out another lease on the > object? Yes, that would be the same thing as incrementing the reference count of one lease. But I think we should supply this operation in a well packaged way. So it's mostly about the choice of names for these functions I think. We have functions to create a lease, to duplicate a lease and to return a lease. We can call the latter two ref/unref or give them more tasty names, of course. Hmm, but isn't there a difference between duplicating a lease and merely addiung a reference to it when the lease has a copy of the original vector? A duplicated lease would have to have another copy then, right?