Smalltalk › Squeak › Squeak - Dev

[FFI] ExternalStructure ownership (or not) of memory

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 6 messages Options
Schwab,Wilhelm K
Reply | Threaded
Open this post in threaded view
♦
♦
|

[FFI] ExternalStructure ownership (or not) of memory

Schwab,Wilhelm K
Hello all,

Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized.  How do I distinguish the two cases?  One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right?

Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it.

What should I be asking? :)

Bill


johnmci
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [FFI] ExternalStructure ownership (or not) of memory

johnmci
In dealing with the case where you have a Smalltalk object that is paired to a external object where you want to ensure both are freed (at some point).  There are two choices

(a) You store a reference (somehow) to the external object in your smalltalk object. This can be some sort of index number that the external logic understands how to turn that into a reference to the memory, or you store the bytes for a memory pointer in the smalltalk instance.  Don't forget issues with 32 or 64 bit memory addresses.   You then always send your smalltalk object a release method that ensures it's external memory usage is cleaned up, either by using the memory pointer bytes or the index handle, when you decide to dispose of the smalltalk object. The release method then talks to the external interface to dispose of the external memory.

(b) Like above, but you use Finalization to ensure external memory gets cleaned up when the Smalltalk object goes away.



On 2010-04-02, at 5:17 PM, Schwab,Wilhelm K wrote:

> Hello all,
>
> Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized.  How do I distinguish the two cases?  One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right?
>
> Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it.
>
> What should I be asking? :)
>
> Bill
>
>
--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================







smime.p7s (3K) Download Attachment
Andreas.Raab
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [FFI] ExternalStructure ownership (or not) of memory

Andreas.Raab
In reply to this post by Schwab,Wilhelm K
I would suggest that you only register a finalizer for objects where you
*do* have responsibility to reclaim them. There are no implicit
finalizers registered for any subclasses of ExternalObject by default -
the only thing that happens is that all handles are cleared when the
image is restarted.

Cheers,
   - Andreas

On 4/2/2010 5:17 PM, Schwab,Wilhelm K wrote:

> Hello all,
>
> Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized.  How do I distinguish the two cases?  One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right?
>
> Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it.
>
> What should I be asking? :)
>
> Bill
>
>
>


Schwab,Wilhelm K
Reply | Threaded
Open this post in threaded view
♦
♦
|

RE: [Pharo-project] [FFI] ExternalStructure ownership (or not) of memory

Schwab,Wilhelm K
Andreas,

So ExternalStructure>>free is not invoked by default?  Sady to say, I never even considered that possibility.

Bill




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Andreas Raab
Sent: Friday, April 02, 2010 8:24 PM
To: The general-purpose Squeak developers list
Cc: [hidden email]
Subject: Re: [Pharo-project] [FFI] ExternalStructure ownership (or not) of memory

I would suggest that you only register a finalizer for objects where you
*do* have responsibility to reclaim them. There are no implicit finalizers registered for any subclasses of ExternalObject by default - the only thing that happens is that all handles are cleared when the image is restarted.

Cheers,
   - Andreas

On 4/2/2010 5:17 PM, Schwab,Wilhelm K wrote:

> Hello all,
>
> Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized.  How do I distinguish the two cases?  One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right?
>
> Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it.
>
> What should I be asking? :)
>
> Bill
>
>
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Andreas.Raab
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [FFI] ExternalStructure ownership (or not) of memory

Andreas.Raab
On 4/2/2010 8:37 PM, Schwab,Wilhelm K wrote:
> Andreas,
>
> So ExternalStructure>>free is not invoked by default?  Sady to say, I never even considered that possibility.

It's not. Memory is cheap :-)

Cheers,
   - Andreas

> -----Original Message-----
> From: pharo-project-bounces-bM+ny+RY8h+a+bCvCPl5/[hidden email] [mailto:pharo-project-bounces-bM+ny+RY8h+a+bCvCPl5/[hidden email]] On Behalf Of Andreas Raab
> Sent: Friday, April 02, 2010 8:24 PM
> To: The general-purpose Squeak developers list
> Cc: Pharo-project-bM+ny+RY8h+a+bCvCPl5/[hidden email]
> Subject: Re: [Pharo-project] [FFI] ExternalStructure ownership (or not) of memory
>
> I would suggest that you only register a finalizer for objects where you
> *do* have responsibility to reclaim them. There are no implicit finalizers registered for any subclasses of ExternalObject by default - the only thing that happens is that all handles are cleared when the image is restarted.
>
> Cheers,
>     - Andreas
>
> On 4/2/2010 5:17 PM, Schwab,Wilhelm K wrote:
>> Hello all,
>>
>> Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized.  How do I distinguish the two cases?  One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right?
>>
>> Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it.
>>
>> What should I be asking? :)
>>
>> Bill
>>
>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project-bM+ny+RY8h+a+bCvCPl5/[hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Schwab,Wilhelm K
Reply | Threaded
Open this post in threaded view
♦
♦
|

RE: [Pharo-project] [FFI] ExternalStructure ownership (or not) of memory

Schwab,Wilhelm K
Andreas,

Humor aside, it is an important consideration for a system that is to be able to run for any length of time.  So far, I appear to be having good results in that area (yup, my servers are still running), but I am working on something that could turn into a real resource hog if it does not clean up after itself.  I *think* the cleanup is limited to other wrapper objects, and the structs are largely just a convenience for accessing memory allocated elsewhere - I think ~:0

Thanks!

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Andreas Raab
Sent: Saturday, April 03, 2010 12:33 AM
To: The general-purpose Squeak developers list; Pharo Development
Subject: Re: [Pharo-project] [FFI] ExternalStructure ownership (or not) of memory

On 4/2/2010 8:37 PM, Schwab,Wilhelm K wrote:
> Andreas,
>
> So ExternalStructure>>free is not invoked by default?  Sady to say, I never even considered that possibility.

It's not. Memory is cheap :-)

Cheers,
   - Andreas

> -----Original Message-----
> From:
> pharo-project-bounces-bM+ny+RY8h+a+bCvCPl5/[hidden email]
> g
> [mailto:pharo-project-bounces-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0@public.
> gmane.org] On Behalf Of Andreas Raab
> Sent: Friday, April 02, 2010 8:24 PM
> To: The general-purpose Squeak developers list
> Cc: Pharo-project-bM+ny+RY8h+a+bCvCPl5/[hidden email]
> Subject: Re: [Pharo-project] [FFI] ExternalStructure ownership (or
> not) of memory
>
> I would suggest that you only register a finalizer for objects where
> you
> *do* have responsibility to reclaim them. There are no implicit finalizers registered for any subclasses of ExternalObject by default - the only thing that happens is that all handles are cleared when the image is restarted.
>
> Cheers,
>     - Andreas
>
> On 4/2/2010 5:17 PM, Schwab,Wilhelm K wrote:
>> Hello all,
>>
>> Suppose I have a pointer to a structure and I do or do not have the responsibility of reclaiming the memory when a corresponding ExternalStructure sub-instance is finalized.  How do I distinguish the two cases?  One idea I had is to explicitly set the handle to nil if I do not own the memory, but (please correct me if I'm wrong), I can't do that while I'm still using the instance because it will presumably use the handle in accessing the fields, right?
>>
>> Looking at implementors of #isExternalAddress, maybe the idea is to use a byte array to make a copy of memory and an address to refer to it.
>>
>> What should I be asking? :)
>>
>> Bill
>>
>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project-bM+ny+RY8h+a+bCvCPl5/[hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Free forum by Nabble Edit this page