The GIL doesn't only protect against refcount changes (it's indeed the most important thing though). It also protects against concurrent modification problems of dictionaries, lists, etc. which are also quite critical to python. They can have avoided this by making these objects all threadsafe which would explain the terrible single-thread performance.
While the GIL simplifies python's GC (refcounting with cycle detection) design (the GC can just acquire the GIL when it needs to clean up cycles). It is not necessary. If there was no GIL the refcounting would have to be atomic, but otherwise not much changes.
Go has no thread-safe dictionaries or lists. In fact, it may happily segfault if you try to modify map from different goroutines. You ought to protect concurrent modification by yourself.
I've heard, Java and C# also doesn't protect their default datastructures, but rather they have separate concurrent in a standard library.
Python can choose this way, but Guido just do not want. And it will break C extensions.
It will not segfault in playground, cause playground runs with GOMAXPROCS=1 .
But if you run it with go run it wil happily segfaults. Go's runtime sets up handler for SIGSEGV, so that you still will see backtraces for all goroutines.
This code demonstrates bug in user program: race on concurrent update of interface value. Interface is a struct with two fields: type of value and pointer to value. CPU could not update both fields of this struct atomically. So, programmer should protect update of interface value with mutex (if it could be updated from concurrent goroutines).
The GIL doesn't only protect against refcount changes (it's indeed the most important thing though). It also protects against concurrent modification problems of dictionaries, lists, etc. which are also quite critical to python. They can have avoided this by making these objects all threadsafe which would explain the terrible single-thread performance.
While the GIL simplifies python's GC (refcounting with cycle detection) design (the GC can just acquire the GIL when it needs to clean up cycles). It is not necessary. If there was no GIL the refcounting would have to be atomic, but otherwise not much changes.
funny_falcon 3 points · Jan 2017
Go has no thread-safe dictionaries or lists. In fact, it may happily segfault if you try to modify map from different goroutines. You ought to protect concurrent modification by yourself.
I've heard, Java and C# also doesn't protect their default datastructures, but rather they have separate concurrent in a standard library.
Python can choose this way, but Guido just do not want. And it will break C extensions.
[deleted] 0 points · Jan 2017
Go panics, it doesn't segfault.
funny_falcon 1 points · Jan 2017
So, you didn't pushed hard with concurrent updates on maps.
I've got seg-fault at least twice. It was quite several years ago, though (at the time of Go 1.1).
Go doesn't prevents from segfault "totally". Using "unsafe" package you may make segfault easily.
[deleted] 1 points · Jan 2017
Well Go 1.1 is super old. Today if you get any segfault it is most definitely a bug.
funny_falcon 1 points · Jan 2017
https://play.golang.org/p/TtI9gKLlVZ
It will not segfault in playground, cause playground runs with GOMAXPROCS=1 .
But if you run it with
go runit wil happily segfaults. Go's runtime sets up handler for SIGSEGV, so that you still will see backtraces for all goroutines.[deleted] 1 points · Jan 2017
Thanks. I have to say I've never seen a fault in any of my program and I wrongly assumed this would be handled with a nil panic.
I don't fully understand the code so maybe it's normal that it does this ? I don't know.
funny_falcon 1 points · Jan 2017
This code demonstrates bug in user program: race on concurrent update of interface value. Interface is a struct with two fields: type of value and pointer to value. CPU could not update both fields of this struct atomically. So, programmer should protect update of interface value with mutex (if it could be updated from concurrent goroutines).