On 10/13/06, Asko Kauppi <email@example.com> wrote:
I won't be the best responder, but you will get others.. :)
You are already of great help, party by making me think it over
What I'd consider if I was you, is the syntactic simplicity
(readability, maintainability) of the language you will choose.
Partly, it is about execution speed, but if you choose something that
later on just drools you down because of lack of expression, that's
sacrificing developer resources. I'd _not_ roll my own language.
The application domain is quite limited: "call context" manipulation
in a telecommunication software. Think "Call Processing Language" in
Sip Express Router.
- try it. You didn't refer to the platform you're running on, which
would be vital information to know whether "thousands" is applicable
or not. It's definately not out of the reach (of a modern computer)
anyways. On 20-200MHz embedded, it might be.
You are right, I was quite uninformative.
We are using high performance servers, but on the other hand, the
script which removes the first letter from a string (the international
access digit from the beginning of a called number, say) should not
consume a measurable portion of the resources.
I am sure the manipulation itself is quite efficient, I am woried
about vm startup.
A single call can have about 5 independent script invocations at
different stages of call processing, and we handle hundreds of calls
- memory. How much do you have it; can you have a pool of pre-
initialized Lua states available, that you'd just grab and call per
each invokation. alas:
I was hoping I would not need that. Just too much constant
turnover, not peaks.
- threading. Are the invocations coming sequentially (you'd need just
one lua_State) or N numbers whenever?
Possibly as many as parell calls: indefinite.
- tradeoffs: nothing much. I don't see a single thing where modding
Lua would make it essentially faster for you. Number types, if you're
running without an FPU (surely, you aren't?).
There surely is an (unused) FPU. Again, I'm not trying to speed up
execution, I am worried about vm initialisation, the scripts
themselves are negligably small. However, excuse my suspicion, but
would prefer not to have a long-lived "strategy factory" running in a
- precompiling. You say configuration files, and talk of LuaJIT. If
you can completely pre-do the compilation phase, you'd definately
gain some speed. Question is, if you use the same script multiple
times, precompile. If not..
Yes, the scripts would come from config files, practically never
They in fact constitute configuration of call handling.
They just get run terribly often :-)
> - Can I make sure no script can hurt the host process?
How could they? Meaning yes, you can (should) disable things like
'os.*' table; simply set them to nil or better still never initialize
in your host C module.
Then Lua will only be able to touch what your object bridging allows
it. What exactly you mean by 'hurt'?
Well, that. Segfault my process, corrupt memory, etc.
I'm glad I can't.
Eternal loops could be seen as a way to hurt; but there are ways to
prevent that (timers, mainly).
Yes, I was planning to prime a trigger so no call gets held up in
scripted for longer than a few milliseconds.
> - Can I destructively interrupt the "parse" (or whatever the
> equivalent of dofile is for an in-memory bytecode-compiled script
> which I am sure I can cache and reuse) function when a safety timer
This escapes me; can you rephrase that (or maybe someone else gets it
rights and teaches us).
The above trigger, a separate c++ thread would need to be able to
destroy a vm instance and regain its resources.
Please tell the list where you ended up, and why. Would be
interesting to hear! :)
I'll report back when we make a decision if you guys are interested.
On the other hand, EEL looks quite promissing :-)