Go to content
The Codest
  • About Us
    • Staff Augmentation
    • Project Development
    • Cloud Engineering
    • Quality Assurance
    • Web Development
  • Our Team
  • Case studies
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
  • About Us
    • Staff Augmentation
    • Project Development
    • Cloud Engineering
    • Quality Assurance
    • Web Development
  • Our Team
  • Case studies
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
2021-07-20
Software Development

MOM! He Blocked Threads Again!

Pawel Rybczynski

Software Engineer

 MOM! He Blocked Threads Again! - Image

“Don`t block the event loop…” – you've probably heard this sentence many times… I'm not surprised because it is one of the most important assumptions when working with Node. But there is also a second “thing” which you should refrain from blocking – the Worker Pool. If neglected, it can have a significant impact on application performance and even its security.

Threads

Main thing to remember: there are two types of threads in Node.js: Main Thread – which is handled by Event Loop, and Worker Pool (thread pool) – which is the pool of threads – thanks to libuv. Each of them has a different job. The goal of the first one is to handle non-blocking I/O operations, and the second is responsible for CPU intensive work and also blocking I/O.

diagram of libuv

But what is a thread and how it’s different than a process? There are several differences, but the most important one for us is how the memory is allocated to them. You can think about a process like about an application. Inside each process, there is a chunk of memory dedicated just for this process. So, one process doesn`t have access to the memory of the second one, and this property ensures high security. To establish communication between them, we must do some work. Threads are different. Threads runs inside a process and share the same memory so there is no problem at all with threads sharing data.

However, one issue causes a problem. It's called the race condition. The threads can run at the same time, so how do we know which ends first? It may happen that the first time you run it, the first operation ends first, and next time it may turn out to be the opposite and the second operation ends before the first one. Imagine working with write/read operations under such conditions! A nightmare! It's sometimes very hard to write correct code in a multi-threaded environment.

Also, the multi-threaded languages have a large memory overhead because they create a separate thread for each request; so, if you want to call 1000 requests, they create 1000 threads.

How to deal with such a problem? Use a single thread instead! And that is what Node offers you.

single thread eventloop

As a JavaScript developer I encourage you to watch the movie in which Bart Belder clearly explains the concept of the event loop. The above diagram is taken from his presentation. And if you don't know these terms at all, both Node and Libuv have excellent documentation :)

About blocking

In JavaScript development industry they say that because Node is single-threaded and non-blocking, you can achieve higher concurrency with the same resources than with multi-threaded solutions. It`s true but it is not as beautiful and easy as it may seem.

Since Node.js is single-threaded (JS part), CPU-intensive tasks will block all requests in progress until the particular task is completed. So, it`s true that in Node.js you can block every request just because one of them had a blocking instruction inside. The blocking code means that it takes more that few milliseconds to finish. But do not confuse long response time with blocking. The response from database can take a very long time, but it does not block your process (application).

Blocking methods execute synchronously and non-blocking methods execute asynchronously.

How can you slow down (or block) your event loop?

  • vulnerable regex - a vulnerable regular expression is the one on which your regular expression engine might take exponential time; you can read mare about them here,
  • JSON operations on large objects,
  • using synchronous APIs from Node core modules instead of async versions; all of the I/O methods in the Node.js standard library provide also their asynchronous versions,
  • other programming errors, like synchronous infinite loops.

In that case, since the Worker Pool uses a pool of threads, is it possible to block them too? Unfortunately, yes :( Node is based on a philosophy one thread for many clients. Let's assume that a given task performed by a specific Worker is very complex and needs more time to be finished. As a result, the Worker is blocked and it can't be used to execute any of the other pending tasks until its instructions are executed. As you have probably guessed by now, it may affect the performance. You can prevent such issues by minimizing the variation in Task times by using Task partitioning.

Conclusion

Avoid blocking, that's for sure. If you only can, always choose asynchronous versions of the standard library APIs. Otherwise, after running your app, the client can experience several problems, starting with the degraded throughput and ending on complete withdrawal, which is fatal from the user’s perspective.

Read more:

Why you should (probably) use Typescript

How not to kill a project with bad coding practices?

Data fetching strategies in NextJS

Related articles

Software Development

3 Useful HTML Tags You Might Not Know Even Existed

Nowadays, accessibility (A11y) is crucial on all stages of building custom software products. Starting from the UX/UI design part, it trespasses into advanced levels of building features in code. It provides tons of benefits for...

Jacek Ludzik
Software Development

5 examples of Ruby’s best usage

Have you ever wondered what we can do with Ruby? Well, the sky is probably the limit, but we are happy to talk about some more or less known cases where we can use this powerful language. Let me give you some examples.

Pawel Muszynski
Software Development

Maintaining a Project in PHP: 5 Mistakes to Avoid

More than one article has been written about the mistakes made during the process of running a project, but rarely does one look at the project requirements and manage the risks given the technology chosen.

Sebastian Luczak
Software Development

Why you will find qualified Ruby developers in Poland?

Real Ruby professionals are rare birds on the market. Ruby is not the most popular technology, so companies often struggle with the problem of finding developers who have both high-level skills and deep experience; oh, and by the...

Jakub
Software Development

9 Mistakes to Avoid While Programming in Java

What mistakes should be avoided while programming in Java? In the following piece we answers this question.

Rafal Sawicki
Software Development

A quick dive into Ruby 2.6. What is new?

Released quite recently, Ruby 2.6 brings a bunch of conveniences that may be worth taking a glimpse of.  What is new? Let’s give it a shot!

Patrycja Slabosz

Subscribe to our knowledge base and stay up to date on the expertise from industry.

About us

The Codest – International Tech Software Company with tech hubs in Poland.

    United Kingdom - Headquarters

  • Office 303B, 182-184 High Street North E6 2JA London, England

    Poland - Local Tech Hubs

  • Business Link High5ive, Pawia 9, 31-154 Kraków, Poland
  • Brain Embassy, Konstruktorska 11, 02-673 Warsaw, Poland
  • Aleja Grunwaldzka 472B, 80-309 Gdańsk, Poland

    The Codest

  • Home
  • About us
  • Services
  • Case studies
  • Know how
  • Careers

    Services

  • PHP development
  • Java development
  • Python development
  • Ruby on Rails development
  • React Developers
  • Vue Developers
  • TypeScript Developers
  • DevOps
  • QA Engineers

    Resources

  • What are top CTOs and CIOs Challenges? [2022 updated]
  • Facts and Myths about Cooperating with External Software Development Partner
  • From the USA to Europe: Why do American startups decide to relocate to Europe
  • Privacy policy
  • Website terms of use

Copyright © 2022 by The Codest. All rights reserved.

We use cookies on the site for marketing, analytical and statistical purposes. By continuing to use, without changing your privacy settings, our site, you consent to the storage of cookies in your browser. You can always change the cookie settings in your browser. You can find more information in our Privacy Policy.