before using a Mutex in a programming language, always make sure whether that specific mutex implementation is a recursive mutex (reentrant mutex) or a normal mutex.

Some languages such as C++ have different implementations with clear names:
- std::mutex
- std::recursive_mutex
- std::recursive_timed_mutex
etc...

but some languages such as GDScript's Mutex class only have a single Mutex class and it's a reentrant mutex.

And some other languages such as Golang, do not recommend using a recursive mutex at all.

Why doesn't don't Go developers recommend using a recursive mutex?

Russ Cox from the Go development team:
(SO link, Google group Link)

Tl;dr: They make the project so complex and home to bugs, that their benefits is much much less than their damage.

One thing that people make mistake is: most of the times we assume only calling .lock method on a mutex can cause a deadlock, however .unlock is also very important...

You need to ensure you only call unlock after the mutex has been locked by the current thread, otherwise you may get deadlock, crashes or undefined behavior. (do you notice the "may"? because it entirely depends on the implementation of the mutex, or the platform)

For example, in C++:
- mutex.unlock
- timed_mutex.unlock
- recursive_mutex.unlock
- recursive_timed_mutex.unlock
- shared_mutex.unlock
- shared_timed_mutex.unlock

All of the articles above are saying the same thing:
"The mutex must be locked by the current thread of execution, otherwise, the behavior is undefined."

In other programming languages, such as Golang, you will panic (or exception).

In GDScript? you might get nothing.
no errors, no warnings, no logs, no nothing. since it's built on top of C++.

However, sometimes you might get deadlocks.
if the deadlock happens on your main thread, the whole code editor will freeze.
If you are running an exported game, the game will freeze, no logs.
If you look at event viewer, you will encounter this error:

The program name.exe version 1.0.0.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.

not helpful at all. You will have to put breakpoints yourself and debug the code (painful).

Next thing is that, this might not be reproducible in 100% of cases. for example in my case, it was only happening on macos and windows, the linux version was working fine. Even more confusing and weird.

oh btw if this happens in a background thread...then may God help you 🙏

because as far as I know, Godot's debugger does not fully support debugging background threads yet (idk maybe this is implemented in recent versions of 4.*)

But yes, even if it supports, it will just make you more confused, because even if the editor does not freeze, but things just might not be working the way they are supposed to work...
welcome to concurrency hell (if you don't manage it correctly that is)

A footage of code editor freezing when a deadlock happens due to incorrect call to mutex.unlock...
if I uncomment those lines (which will no longer call unlock method), everything will work fine.

This is because of incorrect call to mutex.unlock method.
related GitHub issue

trailer for Witcher 4 running on Unreal Engine 5.6

https://www.youtube.com/watch?v=i_aRhNcHryA

A tool for exploring each layer in a docker image

https://github.com/wagoodman/dive

An attempt to answer the age old interview question "What happens when you type google.com into your browser and press enter?"

https://github.com/alex/what-happens-when

What is Microsoft doing

lol

The Sunk Cost Fallacy in Software Development

The Sunk Cost Fallacy is when we continue investing in something primarily because we've already invested so much, rather than because it's the best decision going forward.

What it looks like in programming:

"We've already spent 6 months building this custom authentication system. Yes, it has security issues and is hard to maintain, but we can't refactor it entirely now - think of all the work we've already put in!"

The rational decision should ignore past costs (they're "sunk" and can't be recovered) and focus only on:
- Future costs
- Expected benefits
- Alternative options

Real-world example:

Your team spent 3 months developing a custom state management solution for your React app. It's complex, buggy, and new developers struggle to understand it. Redux would solve your problems, but your tech lead says: "We've invested too much time in our solution to abandon it now."

This is the fallacy at work. The time already spent is gone regardless of what you choose next. The right question is: "Which option gives us the best outcome from this point forward?"

How to avoid it?

1. Regularly reassess projects with fresh eyes
2. Be willing to pivot when better options come to mind
3. Focus on future value, not past investment
4. Document decisions to recognize when conditions change

Good engineers know when to build, but great engineers know when to abandon something.

if() function in CSS:

The CSS if() function provides a concise way to express conditional values. It accepts a series of condition-value pairs, delimited by semicolons. The function evaluates each condition sequentially and returns the value associated with the first true condition. If none of the conditions evaluate to true, the function returns an empty token stream.

https://developer.chrome.com/blog/new-in-chrome-137#if

TLDR: facebook (and yandex) android apps would listen on a localhost web address and then websites with their javascript code would tell the browser to connect to it, correlating long-lived sessions in the apps with even incognito sessions in web browsers

they no longer do this since June 3rd, but the method is worth noting

https://localmess.github.io/