Skip to content
This repository has been archived by the owner on Jul 24, 2023. It is now read-only.

GoRoutines #42

Open
iMaxopoly opened this issue Jun 27, 2016 · 4 comments
Open

GoRoutines #42

iMaxopoly opened this issue Jun 27, 2016 · 4 comments
Assignees

Comments

@iMaxopoly
Copy link

This isn't goroutine safe is it?

Are you planning to add go-routine safe features if it is doable?

Thank you.

My preliminary tests crashed when I tried to access multiple URLs using go routines.

@masci
Copy link
Contributor

masci commented Jun 30, 2016

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.

@sbinet sbinet self-assigned this Jul 1, 2016
@sbinet
Copy link
Owner

sbinet commented Jul 1, 2016

(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?

@iMaxopoly
Copy link
Author

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 :)

@Kenson321
Copy link

@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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants