On 25 April 2018 at 23:08, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
I don't understand the default

finalizeResourceData: handle
������ handle isNull ifTrue: [ ^ self ].
������ handle free.
������ handle beNull


when handle is an ExternaData, free is defined as in ExternalStructure class as:

free
������ "Free the handle pointed to by the receiver"
������ (handle ~~ nil and:[handle isExternalAddress]) ifTrue:[handle free].
������ handle := nil.

Theorectical side thought.�� ��I wonder how threadsafe that code for #free is?
Sending two messages between the ~~nil test and nil-assignment��
seems to leave the door open for another thread to erroneously pass the ~~nil test.

IIUC, with an inlined #ifNotNil, the following might be safer (?)

�� �� free
�� �� �� �� "Save handle so its nil assignment is inlined with its #ifNotNil: test, eliminating possible thread change during message sends"
�� �� �� �� |savedhandle|
�� �� �� �� handle ifNotNil: [
�� �� �� �� �� �� savedHandle := handle.
�� �� �� �� �� �� handle := nil.
�� �� �� �� �� ����savedHandle��isExternalAddress ifTrue: [ savedHandle�� free].
�� �� �� �� �� �� ].

cheers -ben
��


but beNull is not defined on nil.

I can define my own finalizeResourceData: but the default one, does not work apparently.



On Tue, Apr 24, 2018 at 2:06 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
hi,

there is nothing like that and I do not recommend messing with the registry in general.
but��� you can always extend the classes for your use, is around��FFIExternalResourceManager.

cheers,
Esteban


On 24 Apr 2018, at 14:48, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:


I'm using autoRelease on some FFIOpaqueObject instances.

I need to test some behavior when I delete explicitly one of these objects. ���How to remove these objects from the finalization list, in order they are not freed two times.

Something like ignoreFinalization ?

--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for machines to execute."
http://www.doesnotunderstand.org/




--
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for machines to execute."
http://www.doesnotunderstand.org/