On Fri, Mar 13, 2015 at 5:08 AM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
>> 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.
I've embedded Python in several production situations. Mostly, in
high-performance server-side code. That GIL was ever-present.
As part of some work back in the mid-90's, I created a set of patches to
*remove* the GIL. David Beazley has an excellent writeup/analysis/review of
I love Python. I'd suggest (re)writing our client in Python. But I would
*not* suggest embedding it. It can be done, yes. It can help, yes. But it
is simply too tricky/brittle for me to truly recommend it.
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.
I don't have direct experience with Lua, but have read/observed it for many
years. This is something that I could get behind as an embedded
*experimental* solution (to move "up" from lower-level C code), based on
what I've read.
Received on 2015-03-13 11:18:39 CET