gpython does not contain a GIL.

However it does not, as yet allow any sort of multiprocessing.

It is my plan to make a threading library which under the hood creates go routines. At this point it will need some sort of locking...

by threading library, you mean exposing a gpython module to the Python interpreter, right?

the skylark Python-like VM has actually the concept of a Thread state that is passed to each API call...

• https://godoc.org/github.com/google/skylark#Thread

WDYT about this?

by threading library, you mean exposing a gpython module to the Python interpreter, right?

Yes. My plan was to make a low level module exposing some go features like goroutines, channels, locks etc, and use that low level module to build up something which was API compatible with the threading module.

the skylark Python-like VM has actually the concept of a Thread state that is passed to each API call...

That sounds like a job for a context passed everywhere. We've already identified somewhere else that would be very useful! Go having no thread local storage makes it very difficult to translate some bits of python.

• https://godoc.org/github.com/google/skylark#Thread

WDYT about this?

I think we'd almost certainly need something very similar! I'd propose to attach it to a context though.

I think we'd almost certainly need something very similar! I'd propose to attach it to a context though.

SGTM. (we should probably make sure extracting informations and/or restoring state from that context.Context isn't showing abysmal performances, though.)

SGTM. (we should probably make sure extracting informations and/or restoring state from that context.Context isn't showing abysmal performances, though.)

Hmm, yes! AFAICS context is implemented as linked list, so the lookup isn't very efficient.