[Parrot-users] Use of vtable "destroy"

[S'orlok Reaves]

Thanks for your answer; it covers everything I was curious about.

Let me elaborate on my use case a bit:

I'm interfacing to a native library (libSFML), and I admit to not being very good at NCI. So what I did was wrap each function call in the simplest way possible. An example of this is sfml::Sprite::GetColor(), which returns a Color&. I chose to duplicate the return value and wrap it in a pointer:


//My function
sf::Color* sprite_get_color(const sf::Sprite* item)
{
  sf::Color* res = new sf::Color(item->GetColor());
  return res;
}

...and let Pointer PMCs do the rest:

.sub 'SPR_GetColor'
  .param pmc item
  .local pmc lib, func
  lib = INT_GetDLL()   #Does what you think it does
  func = dlfunc lib, "sprite_get_color", "pp"
  $P0 = func(item)
  .return($P0)  #$P0 is now dangling
.end

There are several places in my PIR code where I, e.g., get the Color and check its blue component, which requires me to call "game_del_color()" (my own library function) to delete the dangling pointer. 

I was thinking of making my own class "Color", and having it delete the library resource when it itself is collected:

.namespace ['Color']

.sub 'init' :vtable
  $P0 = #Get a pointer via SPR_GetColor()
  setattribute self, 'colorPtr', $P0
.end
.sub 'destroy' :vtable
  $P0 = getattribute self, 'colorPtr'

  game_del_color($P0)
.end

A bit convoluted, and perhaps there is already a better option? I was reading about "managed" structs (I think?), but there was a lot more glue code required in that article. In my case, library functions are simply loaded by name, and I prefer the simplicity. 

In terms of liveliness, I really like the sound of that "timely destruction" that you referenced. It sounds sort of like what C# does, where newly-allocated objects are checked more frequently than long-lived ones. (As a side note, I really don't want to have to delete my objects manually, because the whole reason I'm working in PIR is to get decent automatic memory management.) 

To use an example, the following should collect not long after the function ends:

.sub 'do_nothing'
  .local pmc newColor
  newColor = new ['Color']
.end

Thanks again for your help. I would repeat that, for the most part, Parrot is absolutely lovely to work with, and I really appreciate all the effort that goes into its design.
-->Seth







________________________________
 From: Andrew Whitworth <wknight8111 at gmail.com>
To: S'orlok Reaves <sorlok_reaves at yahoo.com> 
Cc: "parrot-users at lists.parrot.org" <parrot-users at lists.parrot.org> 
Sent: Thursday, December 29, 2011 9:11 PM
Subject: Re: [Parrot-users] Use of vtable "destroy"
 
Great questions. This is the kind of thing we should have more
documentation on in the future.

The destroy vtable is called when the object is collected by the
garbage collector. Because it is called during a sensitive point in
the interpreter execution (in the GC, as the PMC is being destroyed) I
wouldn't try to do too much processing in that vtable, but that's more
of a hunch than an actual rule. Honestly, the destroy vtable is not
used very often.

We used to have a notion of "timely destruction", or PMCs which needed
to be collected as quickly as possible. That doesn't really work with
our newest GC algorithm.  We don't have a way to manually destroy a
PMC at the moment, but we could possibly add that in the future if
there was a demand for it. The programmer would be responsible to
guarantee that the PMC only had one surviving reference and that it
was never accessed again after being destroyed, of course.

What is your use-case? What are you trying to accomplish with this? If
we know a little bit more about what you need we can help find a good
solution for you.

--Andrew Whitworth



On Thu, Dec 29, 2011 at 5:04 AM, S'orlok Reaves <sorlok_reaves at yahoo.com> wrote:
> Good evening,
>
>       I'm having a hard time finding information on this: is "destroy" the
> correct method to override if I want something to be performed whenever an
> object is deleted? I did some searching through src/pmc/object.c, and
> "destroy" was the only method that seemed relevant.
>
>      If not, then what method should I use?
>
>      If so, then I have a follow-up question: What are the guarantees of
> object deletion? Will outstanding objects be deleted when the VM exits
> normally? Is there any way to force an object to be collected/deleted at
> some arbitrary point in time (e.g., when a function exits)?
>
>     I checked through the Parrot docs, but couldn't find anything on object
> deletion. If I missed an obvious source of information, I apologize.
>
> Thanks,
> -->Seth
>
> _______________________________________________
> Parrot-users mailing list
> Parrot-users at lists.parrot.org
> http://lists.parrot.org/mailman/listinfo/parrot-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-users/attachments/20111229/3aa4f6b3/attachment.html>