ExternalAddress and block copy; ByteArray and external calls?

Are there any well-worn ways to move data into and out of external memory?  The best I have been able to uncover are recommendations to either do it one byte at a time (yuk!) or to via bitblt.  Those posts come from several years ago, and include mention that ExternalAddress does not clean up after itself.  Looking in Pharo now, I see #finalize that calls free; have things move along to avoid memory leaks?

There are no conditions in #finalize or #free, which raises questions about whether it is safe to send #free to quickly free memory that will no longer be used?  In Dolphin, I reflexively free ODBC related handles because they quickly pile up and cause problems despite the finalization "water mark."  I am currently working with a data acquisition board and will be needing memory for clearly defined periods.  I also need to get data out of the buffers, which sent me looking for an official way to do so.

To what extent, if any, can String and ByteArray be used as buffers for external calls?  Dolphin made that robust, but there were hints that the gc was slightly tamed to allow it.  The little reading I have done in squeak-dev archives suggests that squeak/pharo is not so forgiving.  Is that true?  Is there a way to request a byte array allocated in a fixed (or whatever the jargon is) heap so that external calls will be safe?

Bill


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Bert,

That's helpful in the extreme.  I still think this type of thing could and should be more obvious from crawling around in the image, and with the memcpy dispatched through something OS specific or exported by the vm so it "just works" on different platforms.  Ironically, the thing that threw this in my face will probably require me to write my own library function (the data are most likely going to end up interleaved in a way I don't want).

The library grabbing the data will indeed linger with the pointer, so that has to be external.  The function I will end up writing can dump data into a byte array.  What about cleanup of the external addresses?  Do they finalize themselves?  Can I safely free them when I know I am done with them?

Bill


Bert Freudenberg bert at freudenbergs.de
Mon Aug 23 21:34:50 UTC 2010

On 23.08.2010, at 23:16, Schwab,Wilhelm K wrote:

> Andreas,
>
> Thanks for code, but should this not be in the image, associated in some way with ExternalAddress and/or ByteArray?
>
> Can I simply use a ByteArray to make a buffer that I pass to an external library?  My understanding is that it could be moved by the gc (ouch!!)  Am I wrong?  If there is a way to instantiate a byte array that won't move, great.  

It won't move while you are calling that library. But it can move after return. So as long as the library does not retain a pointer to the buffer, this will work fine.

If the lib *does* retain the pointer, use ExternalAddress allocate: or gcallocate: to make the buffer, and memcpy to fill it quickly or retrieve the data.

- Bert -



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project