> In the past I'd thought about embedding Python into our sources, but > Python still (after 20 years ...) depends on a global interpreter lock > which pretty much kills any chance of lockless thread-safe code. >
Hence my suggestion for Lua, which doesn't have a GIL, as far as I can find. Nor does it need manual reference-keeping like is needed with Python or Perl. With Lua you can have as many evaluation environments as you want. Instantiating them when crossing a certain API boundary to be used by the library internals. These days, I suppose we'd be looking at something like Go, which can be > linked with C/C++ and also natively export functions that can be called > from C/C++. > Do you mean that the code one writes is exported as a C function? Or that there's a C interface (the latter isn't better than e.g. Lua, Python and Perl, so I assume you mean the former?) Would it be an idea, if we really want this, to come up with a list of requirements and nice-to-haves against which each of the languages brought up should be measured? If we don't do that, we probably go on another 10 years with C only (and another 10... and anothor 10...) -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
