2009/7/13 Felix Klock <[email protected]>: > On Jul 13, 2009, at 8:05 AM, David Rush wrote: > >> [...] I will need to keep a bytevector pinned at the address it >> has when I first push it through the FFI across many different calls > > The short answer: the Larceny FFI has to do this too (my Scheme Workshop > 2008 paper [1] talks a bit about why), so we have some support for it; look > in lib/Ffi/memory.sch.
Ok :) > The long answer: (re: allocating bytevectors that won't ever be collected) This is relatively easily to manage by using an old-style free-list in my user-space. Obviously, this is less than ideal. > Having said that, I *want* to fix the implementation of the procedures used > by the FFI and offer it via the same API. I have thought of ways to use > tricks similar to footnote [2] to get nonrelocatable objects that can still > be reclaimed by garbage collection. I cannot spend time on the problem in > the short term, but if you need better support for this feature than is > currently present, let us know. (If you were to offer to help test > alpha-quality implementations of the feature, that might act as a catalyst > towards getting them implemented.) Hmmm...well better support would definitely help out a lot. I have embarked on skunkworks project re-implementing a 90s-era financial application (currently a monolithic windoesn't app using ODBC) as a server farm to go into a high-volume OLTP environment. I would be happy to test alpha code, assuming that I can transport a bootstrap larceny heap image from a 32-bit debian build because I don't have a properly configured environment for building Larceny on Win32. Past experience leads me to believe that the heaps are fairly portable - unless you know better, of course. ATM, I am trying a hack using foreign-stdlib. That should still leave me close to the kind of interface you would need for pinnable bytevectors because, regardless of the solution you choose for Larceny's implementation, at some point you have to finalize the pinned extent. This is isomorphic to a manual free so it seems like it would be all good. > Part 2. How to replace one previously allocated object with another newly > allocated object > I hope you don't actually need to do this No. And I remember the issue in Smalltalk, and it involved ugly hacks there which are essentially equivalent to the solution you proposed. > We may offer proper support for object pinning in the future; I know Will > has told me that he sees it as the right direction. Yay. Between the workarounds you suggested and the prospects of future features, I'm good to go :) > [2] The other way is to allocate the object to the Large Object Space (LOS); > the Evil hack :) But I will remember it if I ever get back around to my soft synthesizer work. For that one I need big buffers to hand off to windows... david rush -- GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt _______________________________________________ Larceny-users mailing list [email protected] https://lists.ccs.neu.edu/bin/listinfo/larceny-users
