3 ms·
The core dev having worked on new GIL (py3.2) explained this to me. I never said it was magic. But he said GIL is a tool to achieve thread-safety in python wh
by SFJulie 10y ago
The core dev having worked on new GIL (py3.2) explained this to me.
I never said it was magic.
But he said GIL is a tool to achieve thread-safety in python when calling non 'thread safe' code.
I am not him, I will not take on any argument of how it works.
But since ruby GIL is inspired by python GIL let's hear ruby coders:
http://www.rubyinside.com/does-the-gil-make-your-ruby-code-thread-safe-6051.html http://www.rubyinside.com/does-the-gil-make-your-ruby-code-t...
Oh, yes, it seems some people are seeing it my way and that it is a controversial point that can be argued. So I agree to disagree.
Btw, I don't multithread and share states, I multiprocess with 0MQ and communication patterns such as PUB/SUB PUSH/PULL for the obvious reasons that I really think multi-threading is an over-valued and wrong abstraction.
- __david__ 10y ago> I really think multi-threading is an over-valued and wrong abstraction. That's as wrong-headed as thinking it's the only good abstraction. Each style has its place—it really depends on what the code needs to do.
- BuckRogers 10y agoI'd tend to agree with the parent that multi-pthreading is a poor abstraction but I'd add an important note: only systems programmers should be explicitly spinning up pthreads. Explicit pthreading is a poor abstraction for everyone else. Application programmers are probably operating at the 'wrong' level and greenthreads make more sense.
- dkersten 10y agoReal threads are great for implementing things like clojure's core.async or task systems like Intel's Threading Building Blocks. Both of these are super useful and don't work as well with processes instead of threads. I definitely agree that most programmers shouldn't be using threads directly, but they should be available as a building block for higher level abstractions.