On Fri, Mar 13, 2015 at 5:08 AM, Erik Huelsmann <ehu...@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 those patches: http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html 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. >... Cheers, -g
