GoRoutines about go-python HOT 4 OPEN

Not sure what's your issue but you should take care of thread safety at the python level by yourself, ensuring to lock the GIL every time you access the CPython API, whether using go-python functionalities or cgo directly.

from go-python.

(apologies for the belated answer)

No, sbinet/go-python doesn't make any promise about go-routine safety.
Neither does CPython, FTR.

That said, could you explain a bit what you were trying to do?

from go-python.

Hello @sbinet

What I'm trying to do can be better explained by this link: http://spikeekips.tumblr.com/post/97743913387/embedding-python-in-golang-part-2

Evidently, you can see that I am trying to create multiple python environments via goroutines with which I can access any given python module in a concurrent fashion.

As per the aforementioned link, you can see this doesn't seem to be possible because of goroutines inherently being very different from a real thread in nature, in which case, the library https://github.com/liamzdenek/go-pthreads comes to aid and solves the problem, albeit, not as elegantly as one would like with Go.

What I basically wanted, as a feature request, was a pure go-based method to run multiple python modules concurrently using only goroutines. This would help with the various caveats mentioned on the https://github.com/liamzdenek/go-pthreads package github page.

Another thing, I notice with it is that thread.kill, doesn't always work. Just feels very broken.

Thank you for reading this :)

from go-python.

@iMaxopoly Thank you for your informaitons, your research helps a lot. Below is my views after learning your works and some other efforts.

1, use pthread is useful, especially you rewrite the code using just c and libpthread for a demo. In my opinion, if put into production enviroment, just like https://github.com/DataDog/go-python3, in fact DataDog doesn't use this package, so does go-python, it is fit for learning, but when come to complicated situations, use c to handle all the logics and only expose several interface to let cgo call is the best practise, it can avoid many crash without information to debug.

2, you mentioned "thread.kill, doesn't always work", you can try different signal, not just SIGSEGV, but there are still some cases this dose not work, but in fact, use this way is not a good way, python codes should supply a method to terminate for gracefully stop. another bad tips, you can try PyThreadState_SetAsyncExc to throw an Exception to stop the thread, is not a good way too.

from go-python.