Page 2 of 2
Re: Scripting / Extension Language
Posted: Thu Jul 15, 2010 2:16 pm
by NickJohnson
I know: thread-safety is important because I will have many threads each executing Lua scripts at once. All the important structures (i.e. thread-shared structures) in a daemon or tool will be mechanism, and therefore will be implemented in C anyway.
Re: Scripting / Extension Language
Posted: Thu Jul 15, 2010 7:13 pm
by nedbrek
I am considering something similar. I am going to build something Tcl-like (if I don't just import Tcl directly). Tcl has simple parse rules, and was designed for embedding and extensions. It is thread safe, and supports a safe interpreter. The language spec is very stable (some might say too stable
The main drawback is that not many people know it, and some find it a little odd (it is actually more Lisp-like than C-like).
Re: Scripting / Extension Language
Posted: Fri Jul 16, 2010 1:29 am
by Candy
Why should your scripting language be thread safe? Can't you start multiple scripts at a time to compensate for that?
Most of the stuff I would script on a system are long-running tasks that take a long time because of external dependencies (backups f.ex.) that would absolutely not benefit from any threading in my scripting. If you need threading, can't you do it separately?
Concrete example: Shell scripts (bash) aren't multithreaded. They're used the world over for the kind of tasks that I think you're targeting.
Do you really really need threading?
Re: Scripting / Extension Language
Posted: Fri Jul 16, 2010 10:05 am
by NickJohnson
The whole idea is to use it as a scripting language (no threads needed) *and* an extension language for system daemon policy (threads are really, really needed, because daemons are really, really threaded). Bash is never used as an extension language: it is always either called from a process, creating a separate bash process, or run standalone as an executable shell script.
Re: Scripting / Extension Language
Posted: Fri Jul 16, 2010 4:02 pm
by Candy
NickJohnson wrote:The whole idea is to use it as a scripting language (no threads needed) *and* an extension language for system daemon policy (threads are really, really needed, because daemons are really, really threaded). Bash is never used as an extension language: it is always either called from a process, creating a separate bash process, or run standalone as an executable shell script.
You've got a good point. If you want to use it for daemons non-threaded is starting to look pointless. I didn't consider the option of writing daemons in non-compiled languages.