Ok, maybe this is the problem. When I started with my code, I thought it
is better to keep a vm. I got several problems - one of them is the
stack. When a vm is allocated, a stack window is calculated from the
position of the vm var on the stack at creation time down to the maximum
stack size for the vm. If you have many calls between the allocation of
the vm and a call to valCallEx, it might happen, that valCallEx will
fail, because at the time of the call your stack is below the window.

Now I changed my way of working. I create a vm before I call any neko
code (creating a vm is only a low overhead, and doesn't slow your code
much) and my problems are gone.

Cheers,
Adrian.

Benjamin Dasnois schrieb:
> Well by default the limit is indeed 8MB which should be enough I
> think... Anyway, even making it up to 64MB (the maximum allowed by the
> default Darwin kernel) doesn't solve the problem....
>
> Is there some function that I should call when I don't need a VM anymore?
>
> Regards,
>
> On Wed, Mar 18, 2009 at 4:43 PM, Benjamin Dasnois
> <[email protected]> wrote:
>   
>> Hello Adrian,
>>
>> I don't think it's a problem with the stack size since a call to
>> ulimit in bash returns "unlimited"...
>>
>> But I'm going to investigate more in this direction.
>>
>> Regards,
>>
>>
>> On Wed, Mar 18, 2009 at 4:30 PM, Adrian Veith <[email protected]> wrote:
>>     
>>> Benjamin Dasnois schrieb:
>>>       
>>>> Following my project to create a bridge from FUSE to haXe, I still
>>>> have a problem : when my C callback is called and in turns calls the
>>>> haXe/Neko code it works as expected but if the C callback is fired
>>>> many times quickly, the call to the haXe/Neko code fails...
>>>>
>>>> Is it a known issue?
>>>>
>>>>         
>>> can you be more precise, where it fails  ?
>>>
>>> I have a project running, where I call neko code from my delphi code and
>>> vice versa many times in a multi threaded server (I use neko .n modules
>>> as plugins in my server and the .n modules call again delphi code for
>>> some calculations). The only problem I had, is when the stack is low at
>>> generation of the vm, that the subsequent call to vallCallEx will fail.
>>> I use now a minimum stack size of 2MB and the code runs stable.
>>>
>>>
>>> hope that helps.
>>>
>>> Adrian.
>>>
>>> --
>>> Neko : One VM to run them all
>>> (http://nekovm.org)
>>>
>>>       
>>
>> --
>> DASNOIS Benjamin
>> http://www.benjamindasnois.com
>>
>>     
>
>
>
>   

-- 
Neko : One VM to run them all
(http://nekovm.org)

Reply via email to