[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Locking Table Member Additions
- From: Sean Conner <sean@...>
- Date: Tue, 17 Jun 2014 19:03:51 -0400
It was thus said that the Great Andrew Starks once stated:
> On Tue, Jun 17, 2014 at 5:26 PM, Tim Hill <firstname.lastname@example.org> wrote:
> > Couple of things to note. Byte-for-byte, compiler Lua code is very
> > compact. You might find the Lua code to build the table is smaller than the
> > equivalent C code. As others have noted, you might be better served by
> > validating the table when passed to a C function, rather than trying to
> > lock it down proactively (again, probably less code overall to do this).
> I understand the sentiment of the OP. When we started to write our first
> Lua C-API code, we wrote way too much in C. As time has gone on, we've
> replaced all of that. It's much easier to build up models and abstractions
> in Lua and it does not make any difference, for speed.
At work, the test tool I wrote is half Lua, half C, and I wrote it in such
a way that the Lua API mimics very closely the C API, to the point where you
could nearly mechanically translate the Lua into C (the API mimicry is that
close) in case the Lua side proved too slow.
It never proved too slow  and half the time I'm wanting to just rip the
C code out .
 We hit other restrictions, like number of outstanding messages and
slow and hilariously fragile communication links .
 SS7 crap. If what we're using is "the SS7 network stack best of
breed" then SS7 network seriously sucks.
 But it works, and I would have to do some extensive testing of the
code just to make sure I can test the code I'm supposed to test.