Calling a PIR method continuesly from C++ side.

Andrew Whitworth wknight8111 at gmail.com
Mon Feb 7 13:35:01 UTC 2011


I don't like using VTABLE_morph for this purpose (I don't like
VTABLE_morph for any purpose, really). I'm going to refactor this
logic out into a separate function and then I'm going to expose it out
through the embedding API.

For embedding situations, you should not be using the Parrot_PMC_morph
or any other functions from the extending API.

--Andrew Whitworth



On Sun, Feb 6, 2011 at 9:15 PM, Vasily Chekalkin <bacek at bacek.com> wrote:
> Hello.
>
> This method called "VTABLE_morph(interp, CallContext, PMCNULL)".
> Unfortunately (may be) it's not exposed via embed API.
>
> --
> Bacek
>
> On Mon, Feb 7, 2011 at 11:58 AM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
>> This does raise a good point, I feel like there really should be some
>> mechanism to reset the state of a CallContext PMC so it can be reused
>> between invocations of a single Sub. I don't think any such thing
>> exists. I'll take a look around and see what can be done.
>>
>> --Andrew Whitworth
>>
>>
>>
>> On Sun, Feb 6, 2011 at 6:00 PM, Shockwave <vinfobag at gmail.com> wrote:
>>> Hello.
>>>
>>>
>>>
>>> Currently, there is an issue with calling a PIR method continuously from a
>>>  C/C++ program that is meant to stay alive for a long time (>10 minutes).
>>>
>>>
>>>
>>> The use-case is a C++ game engine which calls a C/C++ update function at
>>> least 30 times per second. That update function calls into a PIR method of
>>> some class previously instantiated from C++. The PIR method performs the
>>> logic of the game, before returning to the C++ side so that the game-engine
>>> performs the next iteration.
>>>
>>>
>>>
>>> Currently, in order to avoid a recursion error, a CallContext PMC needs to
>>> be create for every invocation of the PIR method from C++. Because this is
>>> happening at least 30 times per second, it creates a lot of allocation.
>>> Calling an empty PIR method that many times eats lots of memory. This is not
>>> sustainable.
>>>
>>>
>>>
>>> What is the correct way to implement this such that:
>>>
>>> 1)      A recursion error doesn’t happen.
>>>
>>> 2)      Memory consumption remains reasonable.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Vlad
>>>
>>> _______________________________________________
>>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>>
>>>
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>


More information about the parrot-dev mailing list