Re: avoiding copy - Luajit FFI

[Fabio Kaminski <fabiokaminski@...>]

I understand the concerns, to have a secure environment on the lua side..
but thats too bad for byte flow intensive software..
and since we dont have a type system for lua, we kind of get stuck..

(how to have a new entity representing a unsafe byte pointer and is
not a string)

but the thing that bother me is that, if you are controlling a lua vm from C,
its supposed that you know what you are doing.. or if you dont .. this "secure"
environment will get compromised anyway.

why waste several cpu cycles waiting the slow memory (from the cpu
perspective)..

we know that I/O matters a lot, as the latency of applications in
general are far more from I/O bottlenecks
than from machine code optimizations..

i think that sort of thing limits more lua vm from taking more ground
in the application total source code, and importance
since you need to stick with C for doing some things reasonably.. like
intensive I/O.. :(

i would like to have more and more code in lua as possible.. but
without to trade that sort of very important efficiency concern.. :(

On Tue, Jun 7, 2011 at 12:02 PM, Patrick Donnelly <batrick@batbytes.com> wrote:
> On Tue, Jun 7, 2011 at 10:54 AM, Fabio Kaminski <fabiokaminski@gmail.com> wrote:
>> Hi Folks,
>>
>> Im trying to get less memory copy as possible with luajit FFI, and in
>> the api to get your hands in a (void *) or (char *) pointer
>> is copying it through "ffi.string()" wich in turns, will create a lua string..
>>
>> my first question: why cant ffi.string() reuse the given pointer.. vm
>> design? avoid concurrency races  from the C side?
>
> Because you may change the memory later on which violates the
> immutability of Lua strings.
>
> --
> - Patrick Donnelly
>
>