4 ms·

Real threads ... and ... that's probably it.

by cgore 13y ago

Argorak 13y ago
Ruby has real threads now. Java had green threads back then.
- cgore 13y ago
  By "real", I mean native and multi-core. Does that exist now? I think it exists in JRuby, but in MRI?
  - sluukkonen 13y ago
    All major Ruby implementations use OS threads, but the GIL still limits parallelism in MRI.
  - Argorak 13y ago
    MRI has native threads a GIL, but you can already release the GIL and run freely in native extensions. And this is _not_ a property of native vs. green threading. (And shows how shallow the comparison is, given the number of languages that implement green threads mapped to native threads nowadays.)
dragonwriter 13y ago
Real (presumably, that means native) threads are an implementation detail and not a language feature, and both Ruby and Python use native threads in the current main implementation (and Ruby, and I believe Python, also have implementations that use native threads without a GIL/GVL.)
- bad_user 13y ago
  In both languages threads are an added after-thought and no, I disagree with you - multithreading is not an implementation detail. For example, why do you think classes in Java are immutable? Also, I consider the standard library to be a part of the core language, because it is. Python doesn't have many concurrency primitives that are commonly used in Java, even really common ones, like AtomicReference or CountDownLatch. Heck, it doesn't even have volatile variables, let alone ForkJoinPool or other niceties. What's actually in the standard library? Well, the multiprocessing library is now baked in for doing "process-based threading", which really means stuff based on fork() that is unportable, because the language implementors gave up on threads a long time ago. It doesn't stop at concurrency primitives though. For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work. Add to that libraries like NumPy/Scipy that are basically unportable, or Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version, or the myriad other libraries in the ecosystem all written for CPython and expecting a GIL. Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional.
  - Argorak 13y ago
    Thats the case for python. Ruby actually shows that designing a language that runs both on and off the JVM is indeed possible.
  - dragonwriter 13y ago
    > In both languages threads are an added after-thought So? > no, I disagree with you - multithreading is not an implementation detail. Threading is a language feature, not an implementation detail. Whether threads are implemented by way of native threads on the underlying platform (as in JRuby, current CPython or MRI), or green threads in the runtime (as in old MRI, etc.), and, in the latter case, whether the green threads are mapped to native threads on an N:1 (as in old MRI) or M:N (as in the main Erlang implementation) model are implementation details. > For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work. Sure, it could, since you could obviously (at the cost of making interop harder) write a Python implementation with its own garbage collector that ran on the JVM or CLR. You might choose to sacrifice portability for better interop with the languages the platform was designed for, but that's a choice. > Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version Seems to me that's a problem either with Django or the pure python MySQL driver, but not with the Python language. > Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional. Perhaps; I'm less familiar with Python's other implementations than with Ruby's (particular JRuby) which is definitely usable, and definitely uses native threads without a GIL.
didip 13y ago
I'd rather steal from Tcl/Lua/Go: coroutines+channels
- lloeki 13y ago
  Coroutines => Fiber[0] (since 1.9.stg) [0]: http://www.ruby-doc.org/core-2.1.0/Fiber.html http://www.ruby-doc.org/core-2.1.0/Fiber.html

Real threads ... and ... that's probably it.

by cgore 13y ago

Real threads ... and ... that's probably it.

Argorak 13y ago

Ruby has real threads now. Java had green threads back then.

cgore 13y ago
By "real", I mean native and multi-core. Does that exist now? I think it exists in JRuby, but in MRI?
- sluukkonen 13y ago
  All major Ruby implementations use OS threads, but the GIL still limits parallelism in MRI.
- Argorak 13y ago
  MRI has native threads a GIL, but you can already release the GIL and run freely in native extensions. And this is _not_ a property of native vs. green threading. (And shows how shallow the comparison is, given the number of languages that implement green threads mapped to native threads nowadays.)

dragonwriter 13y ago

Real (presumably, that means native) threads are an implementation detail and not a language feature, and both Ruby and Python use native threads in the current main implementation (and Ruby, and I believe Python, also have implementations that use native threads without a GIL/GVL.)

bad_user 13y ago
In both languages threads are an added after-thought and no, I disagree with you - multithreading is not an implementation detail. For example, why do you think classes in Java are immutable? Also, I consider the standard library to be a part of the core language, because it is. Python doesn't have many concurrency primitives that are commonly used in Java, even really common ones, like AtomicReference or CountDownLatch. Heck, it doesn't even have volatile variables, let alone ForkJoinPool or other niceties. What's actually in the standard library? Well, the multiprocessing library is now baked in for doing "process-based threading", which really means stuff based on fork() that is unportable, because the language implementors gave up on threads a long time ago. It doesn't stop at concurrency primitives though. For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work. Add to that libraries like NumPy/Scipy that are basically unportable, or Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version, or the myriad other libraries in the ecosystem all written for CPython and expecting a GIL. Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional.
- Argorak 13y ago
  Thats the case for python. Ruby actually shows that designing a language that runs both on and off the JVM is indeed possible.
- dragonwriter 13y ago
  > In both languages threads are an added after-thought So? > no, I disagree with you - multithreading is not an implementation detail. Threading is a language feature, not an implementation detail. Whether threads are implemented by way of native threads on the underlying platform (as in JRuby, current CPython or MRI), or green threads in the runtime (as in old MRI, etc.), and, in the latter case, whether the green threads are mapped to native threads on an N:1 (as in old MRI) or M:N (as in the main Erlang implementation) model are implementation details. > For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work. Sure, it could, since you could obviously (at the cost of making interop harder) write a Python implementation with its own garbage collector that ran on the JVM or CLR. You might choose to sacrifice portability for better interop with the languages the platform was designed for, but that's a choice. > Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version Seems to me that's a problem either with Django or the pure python MySQL driver, but not with the Python language. > Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional. Perhaps; I'm less familiar with Python's other implementations than with Ruby's (particular JRuby) which is definitely usable, and definitely uses native threads without a GIL.

didip 13y ago

I'd rather steal from Tcl/Lua/Go: coroutines+channels

lloeki 13y ago
Coroutines => Fiber[0] (since 1.9.stg) [0]: http://www.ruby-doc.org/core-2.1.0/Fiber.html http://www.ruby-doc.org/core-2.1.0/Fiber.html