milliele

PyNode是一个轻量级的Node.js C++扩展包,使用Node.js的N-API写成的,能在同一个进程里通过底层C/C++的API实现python和javascript的互操作,只需要进行数据类型的转换,运行效率高。详细的原理讲解可以看我这篇介绍

本文主要简单记录一下使用PyNode的一些实践经验。

下面提到的内容在我这篇介绍里都涉及了,就不赘述了。
注1:PyNode毕竟只是其作者个人开发的小项目,会或多或少有点问题。如果不想这么麻烦的话,可以使用阿里开源的@pipcook/boa,它内置了一个conda的python环境,连python动态库的操作给你一手包办了,应该不会有这么多问题。
注2: 用它的话,最后的主程序还是在Node环境里执行的。要通过C++联通的原理,python调用javascript,请参考stpyv8。或者先用PyNode写一个包装好的JS接口函数(这个接口函数里可以用PyNode调用python程序),参数和返回值都是可以序列化的。然后再通过进程间通信的手段从python里调用javascript,调用这个接口函数。

前提

安装的前提是装好两种语言的runtime。

  • Node.js:没啥特别的,直接装就行了。

    Linux系统安装Node.js可以直接用NVM(Node Version Manager),与python的conda类似。

  • Python:由于PyNode是在Node.js的C++扩展里嵌入了python,因此需要Python的动态/静态库
    一般情况下,cpython官方给的安装版都是由一个动态库(比如在Linux里会叫:libpython3.x.so),和一个依赖该库的小可执行文件组成。这样非常方便其它C++程序嵌入python。
    这种Python通常是通过--enable-shared选项编译安装的,可以在你的python环境里运行:
    import sysconfig
    sysconfig.get_config_vars(\'Py_ENABLE_SHARED\')
    
    这个返回[1]就是true,[0]就是false。true代表着是通过--enable-shared选项编译安装的。
    还有一种更本质的方法,直接看可执行文件依赖的动态库。Linux上可以通过ldd命令,Mac OS上可以通过otool -L命令,查看你的python可执行文件的依赖情况:
    # If your python command is "python3", use `which python3`
    # On Linux: 
    ldd `which python`
    # On Mac OS
    otool -L `which python`
    
    出现结果例如:
    # On Linux
    root@7fe6daacb730:/# ldd `which python`
        linux-vdso.so.1 (0x00007ffe41b47000)
        libpython3.9.so.1.0 => /usr/local/lib/libpython3.9.so.1.0 (0x00007fd5feb2c000)  # python library
        libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fd5feaf2000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd5fead1000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd5feacc000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fd5feac7000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd5fe944000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5fe781000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd5fef08000)
    
    # On Mac OS
    /your/python/executable/dir/venv/bin/python:
        /Library/Frameworks/Python.framework/Versions/3.9/Python (compatibility version 3.9.0, current version 3.9.0)  # Depends on python shared library
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)
    
    说明你的python有动态库,那么PyNode的安装应该不会出现啥问题。

安装

首先,如果python库没啥问题,按项目简介所说,安装前首先确认好你需要使用的python环境,如果要用虚拟环境,也先进入虚拟环境

# Install gyp-next
pip install gyp-next

# Install PyNode
npm install @fridgerator/pynode
# or 
yarn add @fridgerator/pynode

那么,如果你的python不依赖动态库咋办呢?如果你是Conda环境,那么还是有可能找到动态库的:

找到你的Python动态库

适用于Conda环境。一些详细的log可以参考这个Issue。下面的介绍跟我在这个Issue里的comment基本一样的。

如果你用的是Conda环境,恭喜你,他们提供的python,旧一点的,可能会遇到GCC版本低问题,而新一点的,已经直接用静态库build成可执行文件了,再也不依赖动态库了:

(py38) $ ldd `which python`

linux-vdso.so.1 (0x00007ffe03efd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faa187be000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007faa185bb000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faa1821d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faa17ffe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faa17c0d000)
/lib64/ld-linux-x86-64.so.2 (0x00007faa18d5d000)

不过好消息是,Conda声称他们尽管不用,但还是提供了动态库,所以我们只要找到它就可以了。有一个很好用的python包find_libpython,能很好地找到你的python动态库:

(py38) $ pip install find_libpython
(py38) $ find_libpython  # or "python -m find_libpython" /xxx/miniconda3/envs/py38/lib/libpython3.8.so.1.0.

然后我们要做的就是把动态库的目录路径作为库路径添加到PY_LIBS里(-L)。
但这样做链接的时候能找到库,后面执行的时候也还是会找不到,一种解决方法是用rpath把这个路径给他刻烟吸肺,运行的时候也能找到(通过-Wl,-rpath=)。那么加在一起,你的包安装命令就应该是:

PYTHON_SHARED=/xxx/miniconda3/lib PY_LIBS="$(python ../build_ldflags.py) -L$PYTHON_SHARED -Wl,-rpath=$PYTHON_SHARED" npm install @fridgerator/pynode

使用

没啥好说的,使用起来很简单,按项目首页的Readme做就可以了。列一些使用Tips和可能出问题的地方。

const pynode = require(\'@fridgerator/pynode\')的时候动态链接错误

Uncaught:
Error: libpython3.9.so.1.0: cannot open shared object file: No such file or directory
    at Object.Module._extensions..node (node:internal/modules/cjs/loader:1168:18)
    at Module.load (node:internal/modules/cjs/loader:989:32)
    at Function.Module._load (node:internal/modules/cjs/loader:829:14)
    at Module.require (node:internal/modules/cjs/loader:1013:19)
    at require (node:internal/modules/cjs/helpers:93:18) {
  code: \'ERR_DLOPEN_FAILED\'
}

根据*上说,链接时能找到库是一回事,不代表它运行的时候也能找到,运行的时候查找动态库又有另一套路径(……)。

验证方法可以是:
cd进入node_modules/@fri/x/build/Release里,会找到编译好的PyNode.node
然后,ldd PyNode.node

  linux-vdso.so.1 (0x00007ffef7de3000)
    libpython3.9.so.1.0 => not found  # Failed to find when executing
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f976bd9c000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f976ba13000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f976b7fb000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f976b40a000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f976c1bd000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f976b06c000)

就是说,build的时候提供-lpython3.9-L<path_to_shared_library>是明确指定好库,这样生成的文件PyNode.node才包含这个库,换句话说,它才会出现在ldd的list里。

但这个可执行文件运行的时候找共享库,跟build的时候提供的路径没有关系,感觉它像是会在一个给定的路径集合里找,所以这些路径集合里没有libpython3.9.so.1.0,那ldd就会显示not found。

在linux下,一种解决方案是通过往环境变量LD_LIBRARY_PATH里添加这个动态库的目录,例如:如果动态库的绝对路径为/opt/libpath/libpython3.9.so.1.0,那么可以在~/.bashrc里添加一行:

export LD_LIBRARY_PATH="/opt/libpath:$LD_LIBRARY_PATH"

这之后再ldd .node文件,就能找到了:

linux-vdso.so.1 (0x00007ffc01562000)
    libpython3.9.so.1.0 => /opt/libpath/libpython3.9.so.1.0 (0x00007f041a327000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f041a123000)
    libstdc++.so.6 => /mnt/asp_test/env/miniconda3/lib/libstdc++.so.6 (0x00007f041a9be000)
    libgcc_s.so.1 => /mnt/asp_test/env/miniconda3/lib/libgcc_s.so.1 (0x00007f041a9aa000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0419d32000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f0419b2f000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0419791000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0419572000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f041a91d000)

另一种方法是用rpath,就像上面针对Conda环境安装的那样,把动态库的路径同时也加到-Wl,-rpath=里。

ImportError: math.cpython-39-x86_64-linux-gnu.so: undefined symbol: PyFloat_Type

或者类似undefined symbol: PyExc_ValueErrorundefined symbol: PyExc_SystemError的错误。

通常会在Linux上出现,属于是打开动态链接的时候出了问题。PyNode提供了一个dlOpen函数来手动打开动态链接。

  1. 首先肯定是要找到你的动态库,可以使用上文所说的find_libpython包来查找。假设为:
    /opt/libpath/libpython3.9.so.1.0
    
  2. 然后在Node.js里:
    const pynode = require(\'@fridgerator/pynode\');
    pynode.dlOpen(\'/opt/libpath/libpython3.9.so.1.0\');
    

在Node.js里运行Python的multiprocessing

Node.js通过C API起了一个python解释器,这种情况下本进程的可执行程序其实是node。换句话说,sys.argv[0]sys.executable都是指向node的可执行程序。

而python环境中开新的多进程同时运行,会获取当前的可执行程序(excutable),发现竟然不是python,那multiprocessing就读不懂这个可执行程序的信息,比如说找不到main从而报错。

查看源代码后发现了multiprocessing.spawn里的这么一段:

有一个接口set_executable,可以重新设置可执行程序。所以通过PyNode去调用使用了multiprocessing的python程序可以这么做:重新设置executable为你的python可执行程序

比如,我用了virtualenv,我的可执行程序就是:/my/project/path/venv/bin/python

const pynode = require(\'@fridgerator/pynode\');
pynode.startInterpreter();
const sp = pynode.import(\'multiprocessing.spawn\');
sp.get(\'set_executable\').call(\'/my/project/path/venv/bin/python\');
// Run the multiprocessing python code

需要注意的是,这种补丁操作只适用于纯Python的multiprocessing。如果你的某个子进程混入了一些node.js的代码,那么会报错。还没搞懂具体原理,我猜想原因可能是,子进程是通过python可执行程序起的,找不到node环境。

Jest单元测试卡住不会结束

表现是:

  1. 当测试文件多于cpu_count - 1的时候,整个测试程序卡住,不会再进行下一个test suite。
  2. 如果使用--runInBand选项禁止多线程执行单元测试,会Segment Fault

起因是segment fault了,而Jest不知道为啥在多线程跑单元测试的时候(一般一个文件一个线程,开线程的数量是cpu_count - 1),在某些OS里遇到segment fault当前线程就会卡死,所以总共会坚持cpu_count - 1个test suite,然后才卡死。如果文件数据少于cpu_count - 1的话,会顺利运行完。

经过研究,segment fault的原因是:StartInterpreter不可以重复调用2次,因为它里面有一个函数执行的时候需要Python的全局进程锁(GIL),但StartInterpreter在第二次调用的时候不调用Py_Initialize,因此也不重新获取GIL,导致segment fault了。

而Jest的每个测试的环境都是全新的,不管是把const pynode = require(\'@fridgerator/pynode\');放到单独一个文件里require,还是用一个全局变量标记是否已经start Interpreter都无法阻止StartInterpreter被调用2次导致segment fault。

解决办法就是不用Jest 修改源码,不管怎样在调用那个函数前都获取一下GIL(PR)。
这个PR还没被merge进pynode的主分支,想安装这个版本的话,可以下载我fork的repo里的源码

然后在项目根目录里npm pack,会得到一个.tgz文件,然后在package.json里这么写:

"dependencies": {
    "@fridgerator/pynode": "file:./pynode/fridgerator-pynode-0.5.2.tgz"
},

路径就是你的这个文件相对于package.json的路径。

分类:

技术点:

相关文章: