The document discusses concurrency in programming, particularly focusing on Ruby's Global Interpreter Lock (GIL) which prevents multiple threads from executing Ruby code simultaneously. It explains that while the GIL limits true multi-threading in MRI, it allows for some concurrency during blocking I/O operations, enabling efficient execution while waiting for tasks like HTTP requests or database queries. The text concludes by suggesting practical advantages of using concurrency, particularly in client-side operations.

1. Concurrency in production
Real-life example

2. Why do we need concurrency?

3. Program execution ways

4. Why don’t we use it so often?
Multithreaded programming

5. The Global Interpreter Lock
MRI has a Global Interpreter Lock, often called the GIL, and having a high level
understanding of it is important to understanding how we write multi-threaded code
in Ruby. Basically the GIL prevents multiple Ruby threads from executing at the same
time. This means that no matter how many threads you spawn, and how many cores
you have at your disposal, MRI will literally never be executing Ruby code in multiple
threads concurrently. Note that this is not the case for JRuby or Rubinius which do not
have a GIL and offer true multi-threading.
The existance of the GIL provides some guarantees and removes certain issues around
concurrency within MRI. It’s important to note however that even with the GIL it’s
very possible to write code which isn’t threadsafe in MRI.

6. So when does using threads make sense?
To ensure all citizens are treated fairly the underlying operating system handles
context switching between threads, i.e. when to pause execution of one thread and
start or resume execution of another thread. We said above that the GIL prevents
multiple Ruby threads within a process from executing concurrently, but a typical
Ruby program will spend a significant amount of time not executing Ruby code,
specifically waiting on blocking I/O. This could be waiting for HTTP requests, database
queries or file system operations to complete. While waiting for these operations to
complete, the GIL will allow another thread to execute. We can take advantage of this
and perform other work, which doesn’t depend on the result, while we wait for the I/O
to finish.

7. What does it mean in practice?

8. Issue

9. The first idea
Let’s do it on client side...

10. Performing HTTP requests concurrently
At a high level this should
get our timeline waiting for
GET requests from this:
to this:

13. Thanks for your
attention!
Hope you don’t have
questions ;)