Hacker News new | past | comments | ask | show | jobs | submit login

Nice! Does this let you get around the GIL?

I believe so, at least you can in C. You have to release the GIL in your extension, do your business, and cleanup before giving the control back to Pyhton.


Edit: Even though you can do it in C, Go is a no go. Under item four in the caveats [1] is stated:

  | When using goroutines py.Lock must be used. No other 
  | GIL or threading interface functions have been 
  | tested - and they most likely will not work.
[1] http://gopy.qur.me/extensions/

> Calling Go code from a second thread will currently cause the code to raise an exception (i.e. all calls into Go code must be made from the same thread)

That's ... interesting.

I haven't looked at this much (not much of a Python user these days) but presumably you can still multithread your Go code using Go semantics regardless of this restriction. The Go code you call from Python should be able to create goroutines as needed which then report back to the main Go thread as needed, as long as they follow the Go conventions about pointer ownership (channel receiver owns the memory sent to it).

Of course it would be nicer if the main Go thread didn't lock out the Python caller from running (which it seems to do), but there should still be lots of concurrency available on the Go side.

yes. See lock.UnblockThreads(); in the parallel example from the article (the sleep is executed without holding GIL).

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact