uWSGI +构建Go .so无法正常工作

Question

Problem: .so(shared object) as library in python works well when python calls it and fails in uWSGI-running python(Django) application.

More info: I've build Go module with go build -buildmode=c-shared -o output.so input.go to call it in Python with

from ctypes import cdll

lib = cdll.LoadLibrary('path_to_library/output.so')

When django project is served via uWSGI the request handler that calling Go library freezes, causing future 504 in Nginx. After getting in "so called freeze", uWSGI is locked there and only restarting helps to enliven app. No logs AT ALL! It just freezes.

Everything works correctly when i run in python interpreter on the same machine.

My thoughts: i've tried to debug this and put a lot of log messages in library, but it won't give much info because everything is fine with library(because it works in interpreter). Library loads correctly, because some log messages that i've putted in library. I think it some sort of uWSGI limitation. I don't think putting uwsgi.ini file is somehow helpful.

Additional info:

• Go dependencies:

  • fmt
  • github.com/360EntSecGroup-Skylar/excelize
  • log
  • encoding/json

• OS: CentOS 6.9

• Python: Python 3.6.2

• uWSGI: 2.0.15

What limitations can be in uWSGI in that type of shared object work and if there a way to overcome them?

Answer 1

Attempts and thoughts

I tried to avoid separation of shared library from my python code, since it requires support of at least one more process, and i would have to rewrite some of the library to create new api.

As @Lu.nemec kindly noted that:

Go has its own runtime, thread management and may not work well with uWSGI which handles threads/processes in a different way

Since uWSGI is the problem i started seaching for a solution there. One of the hopes was installing GCCGO uWSGI plugin somehow solve that problem. But even it's hard to install on old OSes, because it lacks of pre-builded plugins and manual build haven't gone very well, it haven't helped, nothing changes, it still freezes.

And then i thought that i wan't to disable coroutines and that type of stuff that differs from uWSGI and one of the changes that i am able to do is to set GOMAXPROCS

GOMAXPROCS sets the maximum number of CPUs that can be executing simultaneously and returns the previous setting. If n < 1, it does not change the current setting. The number of logical CPUs on the local machine can be queried with NumCPU. This call will go away when the scheduler improves.

And it worked like a charm!!!

The solution

import (
    ...
    "runtime"
)
...
//export yourFunc
func yourFunc(yourArgs argType) {
    runtime.GOMAXPROCS(1)
    ...
}