How do people usually write a server if they don't really care about performance? A program starts, then starts accepting incoming connections from clients and starts a new thread for each client, which is engaged in servicing this client. If you use framework, like Spring or Flask or Poco there, then it does something like this inside itself - the only difference is the threads can be reused, that is, taken from a certain pool. It's all quite convenient, but not too effective (and Spring is bad). Most likely, your threads serving clients do not live long and most of the time they are waiting either to receive data from the client or to send it to the client - that is, they are waiting for some system calls to return. Creating an OS thread is quite an expensive operation, as is context switching between OS threads. If you want to be able to serve a lot of customers efficiently, you need to come up with something else. For example, callbacks, but they are pretty inconvenient (though there are different opinions on this).

Another option is to use non-blocking I/O in combination with some kind of implementation of user-space threads (fibers). In this article I will show you how to write all this with your own hands.

Как обычно пишут сервер, если не особо заботиться производительности? Программа запускается, затем начинает принимать входящие соединения от клиентов и для каждого клиента запускает новый поток, который занимается обслуживанием этого клиента. Если вы используете какой-нибудь, прости господи, Spring или Flask или там Poco, то он что-такое внутри себя и делает - разве что потоки можно переиспользовать, то есть брать из некого пула. Это всё довольно удобно, но не слишком эффективно. Скорее всего, ваши потоки, обслуживающие клиентов, живут недолго и большую часть времени ожидают либо получения данных от клиента, либо отправки их клиенту - то есть ждут возвращения системных вызовов. Создание потока ОС - довольно дорогая операция, как и переключение контекста между потоками ОС. Если вы хотите уметь обслуживать много клиентов эффективно, надо придумать что-то другое. Например, коллбеки. Но это довольно неудобно.

Цель настоящей статьи - изучить лямбда функции: чем они отличаются от обычных функций и изучить, как они реализованы в С++, Python 3 и Java.

На протяжении этой статьи я буду использовать godbolt.org, чтобы компилировать код и изучать машинный код или байт код. Я думаю, что при чтении статьи может быть удобнее смотреть не на приведённый машинный код в статье, а на этом сайте.

The point of this article is to explore Lambda functions, their dirrerences from regular functions and how they are implemented, based on C++, Python and Java programming languages.

Throughout this article I will be using godbolt.org to compile code and see machine code or byte code.

Эта статья написана по мотивам моей курсовой работы, основной смысл которой описан здесь. В процессе работы над ней мне понадобилось добавить в учебной ОС, над которой я работал, поддержку thread_local переменных, о чём я и хочу здесь рассказать в надежде что кому-то это окажется полезно.

Здесь рассмотрен совсем простой случай: поддержки динамической загрузки других бинарников не будет, а способ реализации рассмотрен только один.

Код расположен в двух репозиториях.

В языке С есть функции malloc, free и realloc. При использовании последней вы можете написать этакий расширяющийся массив из примитивных типов или структур (классов-то нет), который, можно надеяться, не будет копировать все данные при каждом расширении. В С++ есть встроенный класс vector, который представляет из себя расщиряющийся массив, но он так не умеет: при каждом расширении вектора выделяется новый участок памяти и все элементы перемещаются на него (по возможности, с использованием move-семантики). Но ведь, если можно каждый раз не копировать все старые элементы на новое место, вектор должен работать быстрее? В этой статье я попробую написать вектор, который умеет расширяться без копирования элементов.

Код приведён здесь.

Сначала я покажу, что стандартный вектор не умеет расширяться без копирования/перемещения, потом обсужу придуманное решение, потом собственно приведу реализацию вектора, а в конце сравню производительность со стандартным вектором.

Когда я работал над своей курсовой про то, как передавать С++ исключения из ядра ОС пользовательским программам, я изучал, как работают исключения в С++ и в этом мне очень помогла эта серия статей с Хабра. Теперь я хочу дополнить некоторые мометны, которые недостают в этой серии статей.

В Clickhouse есть интересный код: при вызове одной функции происходит перевод области памяти исполняемого кода программы на использование Huge Pages. В процессе весь код программы копируется на новое место, память, использовавшаяся изначально для кода программы возвращается ОС, а потом запрашивается снова. Эта статья основана на соответствующей части доклада с Я.Субботника.

Сначала мы посмотрим, что такое виртуальная память и TLB, потом перейдём собственно к Clickhouse, посмотрим, почему там пришла идея делать такие махинации с бинарником в памяти, а в конце посмотрим, как это всё реализовано.

Эта статья написана по мотивам дипломной работы, выполненной в ВУЗе. Мне показалось, что она могла бы быть интересна и другим людям, поэтому выкладываю пересказ. В этой работе я кратко рассмотрю, как вообще работают исключения в С++, опишу, как я добавил их поддержку в простую ОС, написанную для преподавания АКОСа, какой способ передачи исключений из ядра в программы я написал. А в конце посмотрим, в каких ещё случаях ОС может бросать пользователям С++ исключения.