Василий Дёмин

Все, абсолютно все люди путают транзакции с блокировками. Это какая-то массовая галлюцинация.
Хотя там все просто, как 2х2
Транзакции используются для консистентности. Чтобы когда выполняется больше одного запроса, изменяющего данные, то были выполнены либо все, либо ни одного.
А чтобы не было race condition используются блокировки.

Делаете SELECT FOR UPDATE, который блокирует строку, чтобы больше никто из нее не мог читать. Любой процесс, который захочет прочесть это же значение, будет стоять и ждать.
Дальше вы делаете свои проверки, и потом сам апдейт, который отпустит блокировку.
Процесс, который ждал своей очереди, получит уже измененное значение, и проверка не пройдет.

Как работает, так и тестировать.
Если тестируется продюсер - запустить его и посмотреть, что нужное сообщение появилось в очереди (сделать тестового консюмера).

Если тестируется консюмер - запихнуть сообщение в очередь и посмотреть, что консюмер отреагирует на него ожидаемым образом за отведённое время. (Делаем тестового продюсера)

Обычно по поводу Kali совет дают один - вернись к майнкрафту :)

Человек, который ставит Kali - не должен задавать такие вопросы.
Человек, который задает такие вопросы - не должен ставить Kali. Если руки чешутся поставить линух - возьми астру какую-нибудь или simply linux.

mas уже указатель. Массивы в C - указатели. Не надо & использовать где вы его возвращаете. Только в этом случае оно скомпилируется, но работать не будет, потому что mas - локальный массив. По выходу из функции это будет указатель на отчищенную память. Надл выделять массив через malloc.

А отвечающим откуда знать? Если бот будет асинхронным - используйте. Если нет - в чем тогда смысл?

select 
   manga_id, 
   count(manga_id) as cnt 
from manga2likes
group by manga_id
order by cnt

А я за NULL! При ForeignKeys - корректное поведение, при unique - корректное поведение, при JOIN корректное поведение.
FK позволяют организовать целостность данных на уровне БД (CASCADE/RESTRICT/ SET NULL -это уже от бизнес логики) и там нет ON DELETE SET 123 или ON DELETE SET 0, что говорит само за себя, как и NULL значения при LEFT JOIN.
unique (column):
null
null
1
2
...
- и это нормальное и правильное поведение, т.е. значения уникальны, если они указаны. С 0 или суррогатным значением так не выйдет и будет расти еще один костыль.
По поводу экономии места - в нынешних реалиях, экономия на спичках.
Про обработку NULL / NOT NULL -если используется ORM либо обертка какая, то там это обычно реализовано прозрачно. К примеру Yii2: ArModel::findOne(['col' => null]) само развернет в нужный SQL код. В других фреймворках думаю тоже.
P.S. Имею ввиду MySQL, в других БД возможно по другому.

Обычный парсинг с сохранением авторизационных куки

Говорят, скоро никаких профессий не останется, только составители промтов к искусственному интеллекту.
Так что надо потихоньку учиться выражать свои желания словами (хотя злые языки утверждают, что этому учат в средней школе на уроках литературы, и по идее совершеннолетний недоросль уже должен этим искусством владеть).
И если задать мирозданию вопрос не "как объединить два файла", а написать то, что на самом деле нужно,
bash сделать из двйх файлов один с двумя колонками
то гугль прекрасно найдет вам ответ, даже без всякого ИИ.

В данный момент на m1 можно запустить только Asahi Linux.

Ты должен спрашивать какие алгоритмы игровой графики бывают. Это важное. А константа - это просто реализация.

Почитай Генри Уоррена - Алгоритмические трюки для программистов. Там есть всякое. Деление через умножение на магию. Умножение через сдвиги. Дискретные логарифмы и корни и прочее.

1. Не все задачи можно распараллелить в принципе.
2. Некоторые задачи распараллелить нетривиально
3. Обработка небольших объёмов данных происходит быстрее в однопотоке из-за того что многопоток добавляет по сравнению с ними слишком много накладных расходов.