About concurrency and the GIL

>(since the above argument can be made that those workloads would be better in a different language).

Thats a pretty self defeating argument. Every single possible ruby workload would perform better in another language.

>So, asking for GIL removal is asking all users of the language to pay a 'threading tax',

First, the existence of the multithreading support already has a threading tax, the GIL. Second, sprinkling in the use of some more mutexes wouldn't make a significant performance impact, especially not in a interpreted language that we already agree is not good for performance.

Of course, if the runtime knew it was only running one thread it could ignore much the synchronization code altogether, but we don't want to pay the tax of a single branch decision, do we?

>IMHO, if the resource difference between processes and threads is significant [...]

What about all situations where you want to use threads, but not due to resource constraints? I would assume your answer would be "don't use threads" but you say you're not rabidly anti-thread.

  lock(some_obj) do
    // synchronized code here
  end

JRuby and (sharpish) Rubinius can already do GILless ruby execution. But that doesn't mean everything "just works", it only exposes the problems both languages have when two concurrent contexts try to update the same object, like adding hash elements at the same time. In JRuby it throws an exception, at least allowing you to retry, Rubinius is copying that behavior as well. But technically, there is no standard for what happens.

My knowledge of non CPython interpereters isn't enough to talk about their GIL or lack thereof implementations.

There is hardly any "context switch" if you run one process per core (compared to one thread per core, it makes no difference).

And yes, you'll save memory if you do everything in one process (even with COW), but don't forget garbage collection with multiple threads is a much more complex beast than single-threaded, resulting in extra overhead.

I'm not denying that threads have some advantages, for example, when parallelizing heavy number-crunching work, but the point I was trying to make is that "they are much more efficient" is not that clear-cut and universally true.

That's because it IS more convenient to use threads instead of processes in most cases

Not necessarily true either. When using threads there is a much larger chance of introducing race conditions and deadlocks and other synchronization fails. It might look more convenient when writing the code, but debugging and supporting it certainly isn't.

I would say that a reasonable rule of thumb is that if your problem/workload is at the point where you want to scale vertically - or you are at all concerned about processor cache locality - your 1st step would be to avoid using an interpreted language.

i.e. I don't see this as an argument for having a threaded interpreted language.

Why do you say that? What exactly do you mean? Please assume I'm not a server hacker (I'm not, but I AM a computer scientist).

(BTW, not trying to pick - I am genuinely curious if there is something here I wasn't aware of, which I consider very likely.)

If you're talking about threads implemented by a language runtime (which may execute its own concept of threads on top of kernel threads), then the above may not apply. And on Windows, I understand that there is a real difference between threads and processes, although I have no systems programming experience with it.

As for 'simpler', as long as you aren't actually implementing the thread safe map, it is simpler than using memcache too.

So as long as you use well written shared state implementations, (e.g. Java's concurrent collections), shared state isn't as hard as you make it out to be.