Re:Let's Remove the Global Interpreter Lock
by titanix88 on Wednesday August 16, 2017 @01:20AM
(#15025124)
This! Try to implement a controlled task scheduler using multiprocessing and sooner or later you are going to hit some unexpected behavior, like - multiprocessing.Queue belly-upping for no reason, UNIX signals propagating throughout the process chain and killing them left and right, hitting some data/object which are not serializable etc. Getting multiprocessing to work right takes a LOT of careful efforts, which breaks the whole promise python.
I've since moved to clojure, which is a language designed with concurrency from ground up. Look at clojure's `atom` - it's basically what every beginning programmer expects from globally shared variables, minus the gymnastics of handling race conditions on your own.
Also, `core.async` is such a beautiful thing to work with for writing schedulers. Compared to this, python's asyncio is an unfunny joke.
I don't think python's GIL can be removed with ad-hoc locking. Nothing sort of complete re-implementation will do.
Re:Let's Remove the Global Interpreter Lock
by astrodust on Tuesday August 15, 2017 @02:14AM
(#15015935)
Exactly! If a feature is good it's worth adding, and the GIL in any language is not good.
People are just as quick to bemoan a language for not having something (generics, templates, pre-processors) because they see some perceived need, but a GIL is never one of those things.
But I've never heard of someone asking for a GIL to be added to the JVM.