4 ms·

Threads are out. You can use processes, or async/events, or both processes and async/events, but definitely not threads. Threads are out. Can anyone expound on

Threads are out. You can use processes, or async/events, or both processes and async/events, but definitely not threads. Threads are out. Can anyone expound on this? Because the author certainly doesn't.

wmf 17y ago
It's not clear whether he's saying that threads are bad in Ruby, which is true because of the GIL, or that threads are bad in general, which is just unfounded bashing.
- defunkt 17y ago
  It's not just the GIL. Check out Joe Damato and Aman Gupta's awesome presentation from this year's Hoedown for more info on concurrency in Ruby: http://timetobleed.com/ruby-hoedown-slides/ http://timetobleed.com/ruby-hoedown-slides/
- ryah 17y ago
  > which is just unfounded bashing. i'm always surprised to hear things like this. it's certainly not unfounded - it's just so obvious and universally accepted that it doesn't require explanation - one would think.
  - dschobel 17y ago
    I think it may be obvious to people with a c/++ background, but when I was in school in the early 2000's, they taught you concurrent programming in Java via threads. And the concurrency primitives and frameworks in languages like Java and C# are so easy to use there's a whole generation of us who think that threading is the easy way to do concurrency.
    - jshen 17y ago
      threading is not easy in java. Check out http://www.javaconcurrencyinpractice.com/ http://www.javaconcurrencyinpractice.com/
jmtulloss 17y ago
Thread programming is hard. A lot of people point out different ways of doing it and say "if you're not a terrible programmer, threads work fine", which is all well and good, but they are still much more error prone than async and process models. This is one of the reasons Apple wrote GCD, which is a very interesting approach to threading that makes the messy parts of dealing with threads easier. I would agree with the author. Unless you have a compelling reason to use threads, processes and async tend to make for more correct programs. However, they're often more difficult to get started with. Trade-offs, it's what we do :).
CitizenKane 17y ago
Generally, threads are difficult to use because of what is known as the shared data problem. With threads, generally some global data structure is shared among all the threads. These threads write to and read from this data structure, and those operations are interleaved. This means that if not careful, when a thread is reading data, that data could be corrupted by a another thread writing data into the same data structure. This in turn means that threads need to lock the data structure when they are accessing it so that other threads can't get to it. This leads to a whole host of potential problems that can be very difficult to debug because many of them end up depending on subtle timing differences. Processes avoid this because they can't have shared data. So instead the problem is broken up between processes and message passing is used to share data in between those processes. It's something that generally makes life easier to understand and steers clear of problems that can be very difficult to reproduce and debug.
- blasdel 17y ago
  Processes don't share mutable data, not without explicitly using IPC. In nearly all Unixes, both processes share their entire address spaces after the fork(), just immutably -- pages are only copied when they're written to by one of the processes, otherwise they are shared till exit. Copy-on-write is what makes fork() tractable performance-wise.
  - easp 17y ago
    Copy-on-write is also why people overestimate Apache memory consumption so dramatically and then get into the hassle of running php apps under fcgi to save a trivial amount of memory.
ubernostrum 17y ago
For a while now I've had a feeling that threads -- in the sense of constructs manually created and manipulated directly by an application developer -- are going to go the way of manual memory management. There are still problem domains where you need to obsessively and manually handle memory, there are still people who don't work in such domains but have convinced themselves they do, and there are still people who feel, for whatever reason, that C or C++ are the only tool for Real Programmers(TM). But the trend is and for many years has been away from that and toward managed runtimes, because they're far less complex to work with and far less susceptible to the sorts of easy errors which plague C/C++. I think that a few years down the line we'll be in a similar situation with threads: there will still be problem domains where you absolutely need them, and people who still believe for whatever reason that manually managing a thread pool and shared resources will make their penis bigger, but most of the world will be moving on to something that's less complex and less error-prone, and probably managed automatically by a language runtime or something similar.
- varikin 17y ago
  I agree with this. I was talking to a someone recently who works on embedded system. They do quite a bit of threaded code to deal with network, UI, and other aspects. I mentioned I prefer message passing and processes to threads. His response was that in the limited resources of their devices, that was not feasible. Shared memory and a single process saved on very valuable limited memory. I mainly work on server side code where for the most part, the overhead of a separate process is not issue. The overhead of not sharing memory is not an issue.
acg 17y ago
There is a link in the article to a presentation. The author has not used threads because (apparently) threads in Ruby are green-threads. These are not that useful for a type of application that needs to block on I/O. This also breaks the idea that Ruby=Unix somewhat: far more power is available when native threads are available including the ability to make use of multi-CPU.
- chuckfouts 17y ago
  In MRI Ruby 1.8, Ruby creates a single native thread and all other threads run in that native thread. In Ruby 1.9, each Ruby thread is a native thread. In JRuby, Ruby uses native threads created via the JVM. Not sure about IronRuby, Rubinus, or Ruby EE. A tangled web of options for sure.

wmf 17y ago

It's not clear whether he's saying that threads are bad in Ruby, which is true because of the GIL, or that threads are bad in general, which is just unfounded bashing.

defunkt 17y ago
It's not just the GIL. Check out Joe Damato and Aman Gupta's awesome presentation from this year's Hoedown for more info on concurrency in Ruby: http://timetobleed.com/ruby-hoedown-slides/ http://timetobleed.com/ruby-hoedown-slides/
ryah 17y ago
> which is just unfounded bashing. i'm always surprised to hear things like this. it's certainly not unfounded - it's just so obvious and universally accepted that it doesn't require explanation - one would think.
- dschobel 17y ago
  I think it may be obvious to people with a c/++ background, but when I was in school in the early 2000's, they taught you concurrent programming in Java via threads. And the concurrency primitives and frameworks in languages like Java and C# are so easy to use there's a whole generation of us who think that threading is the easy way to do concurrency.
  - jshen 17y ago
    threading is not easy in java. Check out http://www.javaconcurrencyinpractice.com/ http://www.javaconcurrencyinpractice.com/

jmtulloss 17y ago

Thread programming is hard. A lot of people point out different ways of doing it and say "if you're not a terrible programmer, threads work fine", which is all well and good, but they are still much more error prone than async and process models. This is one of the reasons Apple wrote GCD, which is a very interesting approach to threading that makes the messy parts of dealing with threads easier. I would agree with the author. Unless you have a compelling reason to use threads, processes and async tend to make for more correct programs. However, they're often more difficult to get started with. Trade-offs, it's what we do :).

CitizenKane 17y ago

Generally, threads are difficult to use because of what is known as the shared data problem. With threads, generally some global data structure is shared among all the threads. These threads write to and read from this data structure, and those operations are interleaved. This means that if not careful, when a thread is reading data, that data could be corrupted by a another thread writing data into the same data structure. This in turn means that threads need to lock the data structure when they are accessing it so that other threads can't get to it. This leads to a whole host of potential problems that can be very difficult to debug because many of them end up depending on subtle timing differences. Processes avoid this because they can't have shared data. So instead the problem is broken up between processes and message passing is used to share data in between those processes. It's something that generally makes life easier to understand and steers clear of problems that can be very difficult to reproduce and debug.

blasdel 17y ago
Processes don't share mutable data, not without explicitly using IPC. In nearly all Unixes, both processes share their entire address spaces after the fork(), just immutably -- pages are only copied when they're written to by one of the processes, otherwise they are shared till exit. Copy-on-write is what makes fork() tractable performance-wise.
- easp 17y ago
  Copy-on-write is also why people overestimate Apache memory consumption so dramatically and then get into the hassle of running php apps under fcgi to save a trivial amount of memory.

ubernostrum 17y ago

For a while now I've had a feeling that threads -- in the sense of constructs manually created and manipulated directly by an application developer -- are going to go the way of manual memory management. There are still problem domains where you need to obsessively and manually handle memory, there are still people who don't work in such domains but have convinced themselves they do, and there are still people who feel, for whatever reason, that C or C++ are the only tool for Real Programmers(TM). But the trend is and for many years has been away from that and toward managed runtimes, because they're far less complex to work with and far less susceptible to the sorts of easy errors which plague C/C++. I think that a few years down the line we'll be in a similar situation with threads: there will still be problem domains where you absolutely need them, and people who still believe for whatever reason that manually managing a thread pool and shared resources will make their penis bigger, but most of the world will be moving on to something that's less complex and less error-prone, and probably managed automatically by a language runtime or something similar.

varikin 17y ago
I agree with this. I was talking to a someone recently who works on embedded system. They do quite a bit of threaded code to deal with network, UI, and other aspects. I mentioned I prefer message passing and processes to threads. His response was that in the limited resources of their devices, that was not feasible. Shared memory and a single process saved on very valuable limited memory. I mainly work on server side code where for the most part, the overhead of a separate process is not issue. The overhead of not sharing memory is not an issue.

acg 17y ago

There is a link in the article to a presentation. The author has not used threads because (apparently) threads in Ruby are green-threads. These are not that useful for a type of application that needs to block on I/O. This also breaks the idea that Ruby=Unix somewhat: far more power is available when native threads are available including the ability to make use of multi-CPU.

chuckfouts 17y ago
In MRI Ruby 1.8, Ruby creates a single native thread and all other threads run in that native thread. In Ruby 1.9, each Ruby thread is a native thread. In JRuby, Ruby uses native threads created via the JVM. Not sure about IronRuby, Rubinus, or Ruby EE. A tangled web of options for sure.