[Parrot-users] Use of vtable "destroy"
Jonathan "Duke" Leto
jonathan at leto.net
Sat Dec 31 04:35:51 UTC 2011
Great to hear about you using Parrot. Is you code (libSFML) available
On Thu, Dec 29, 2011 at 1:10 PM, S'orlok Reaves <sorlok_reaves at yahoo.com> wrote:
> 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
> 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
> .sub 'destroy' :vtable
> $P0 = getattribute self, 'colorPtr'
> 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
> .sub 'do_nothing'
> .local pmc newColor
> newColor = new ['Color']
> 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.
> 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>
>> 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
>> deletion. If I missed an obvious source of information, I apologize.
>> Parrot-users mailing list
>> Parrot-users at lists.parrot.org
> Parrot-users mailing list
> Parrot-users at lists.parrot.org
Jonathan "Duke" Leto <jonathan at leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
More information about the Parrot-users