The Python language has two kind of functions — normal functions that you would use in most cases, and async functions. The latter functions are used when performing network IO in an asynchronous manner. The problem with this division is that async functions can only be called from other async functions. Normal functions, on the other hand, can be called from any functions — however, if you call a normal function that does a blocking operation from an async function, it will block the whole event loop and all your coroutines. These limitations usually mean that when writing an using Python`s asyncio, you can`t use any of the IO libraries that you use when writing a synchronous application, and vice versa, unless a library supports usage both in sync and async applications.

Now, the question is, in case you are developing a large and complex library, that, say, allows users to interact with relational databases, abstracting away (some of) the differences between the SQL syntax and other aspects of these databases, and abstracting away the differences between the drivers for that database, how do you support both sync and async usage of your library without duplicating the code of your library? The way sqlalchemy is organized is that regardless of what database and driver for it you are using, you will be calling functions and methods related to Engine, Connection, etc classes, which will do some general work independent of database, then apply the logic specific to your database and finally, call the functions of your database driver to actually communicate with the database. If you are using Python`s asyncio, the database driver will expose async functions and methods, but the rest of the library that is driver‑independent would ideally remain the same. However, the issue is that that you can`t call the async functions of the driver from the normal functions of the core of the library.

There are two articles on Russian, the author of which writes a virtual machine (interpreter) for executing a simple bytecode and then applies different optimizations to make this virtual machine faster. Besides that, there is a compiler of a simple C-like language into this bytecode. After reading this article and getting familiar with the compiler, I thought that it would be interesting to try writing a virtual machine for this language that would be able to apply JIT-compilation to this bytecode with the libjit library. This article describes the experience of doing that.

I found several articles online that describe the usage of this library, but those that I saw, describe the compilation of concrete programs with libjit, while I was interested in compiling arbitrary bytecode. For people interested in further reading, there is an official titorial, a series of articles and a series of comparisons (in Russian).

The implementation was done in C++ because we aren`t playing games here. All my code is in my repository. The "main" branch has just the interpreter of the PigletVM bytecode; "labels-with-fallbacks" has a partial JIT compilation implementation (that doesn`t support JUMP instructions), "full-jit" has fully working JIT-compilationl; "making-jit-code-faster" makes code generated by JIT work faster and "universal-base-vm*" branches merge the interpreter and JIT-compilation implementations, by implementing a base generalised executor, which can be used for different implementations of PigletVM (both the interpreter and libjit compilation)

На Хабре есть две статьи, автор которых пишет виртуальную машину для исполнения простого байткода, а потом применяет различные оптимизации для ускорения этой виртуальной машины. Кроме того, есть и компилятор простого С‑подобного языка в этот самый байткод. Ознакмившись со статьями и этим компилятором, я подумал, что будет интересно изучить, как написать виртуальную машину этого языка, которая сможет делать JIT‑компиляцию байткода с помощью библиотеки libjit. Опыт этого я и описываю в настоящей статье. В интернете есть статьи, описывающие испльзование этой библитеки, но все, что я видел, описывают генерацию машинного кода с помощью libоit для конкретных программ, а не произвольного байткода: есть официальный tutorial, серия статей и ещё серия сравнений на Хабре.

Весь мой код приведён в моём репозитории.

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, посмотрим, почему там пришла идея делать такие махинации с бинарником в памяти, а в конце посмотрим, как это всё реализовано.

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