Камень в MySQL

Давно хотел полить ядом реализацию MVCC в замечательном MySQL (и MariaDB с XtraDB тоже):

mysql  Ver 14.14 Distrib 5.5.15

tx-A> CREATE TABLE make_deadlock (id int PRIMARY KEY,
                                  sid int,
                                  num int,
                                  INDEX (num)
                                 ) ENGINE=INNODB;
tx-A> INSERT INTO make_deadlock VALUES (1, 1, 1);

-- Поехали!
tx-A> BEGIN;
tx-B> BEGIN;
tx-A> UPDATE make_deadlock SET num = num + 1 WHERE id = 1;
tx-B> UPDATE make_deadlock SET num = num + 1 WHERE sid = 1;
-- Транзакция B ожидает A, понятное дело.
tx-A> UPDATE make_deadlock SET num = num + 1 WHERE sid = 1;
tx-B> ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
-- WTF?!

Две транзакции не поделили одну строчку, какая прелесть. Причина, конечно, простая — в этой гениальной реализации MVCC лочатся не строки, а индексы — но больше похоже, что Монти держит нас за идиотов.

SQL и рекурсия

Довольно таки давно в PostgreSQL реализовали CTE.

Common Table Expression (CTE) — это временные результирующие наборы, определенные в области выполнения единичных инструкций SELECT, INSERT, UPDATE, DELETE. Проще говоря, это вьюха которая определяется на момент выполнения запроса.

Возможно, CTE покажется простой альтернативой вложенных запросов, но прелесть в том что CTE позволяет делать рекурсивные запросы.

Асинхронный HTTP прокси-сервер yup.

Недавно явил свету маленький демон yup. Написан он на ruby, разворачивается в два шага (gem install && run).
Назначение у него простое:

1. принять HTTP-запрос и сразу ответить клиенту,
2. запрос ставится в очередь и пересылается указанному в конфигурации yupd хосту,
3. если пересылка запроса постигла неудача (проблемы с сетью, глюки софта), то повторить через некоторое время.

Это можно изобразить диаграммой.
В итоге, получаем маленький модуль на который можно без особого труда делегировать гарантированную и асинхронную отправку HTTP-запросов на какой-либо HTTP-сервис.

Порт xmobar на FreeBSD

Должно быть известно, что xmobar криво работает на FreeBSD, так как прежде всего он ориентирован на Linux и использует /proc.

Однажды, мне надоело созерцать криво работающий xmobar, и я решил заняться его портированием. Заинтересовавшиеся могут пройти по ссылке на github-овский репозитарий. Использовать надо ветку freebsd-port.

Основная цель: портировать не в ущерб основной реализации, так как возможно когда-нибудь будет отправлен некоторый patch set автору xmobar-а.

Пока что реализован монитор памяти. В планах починить сеть.

Критика и предложения мною с большим удовольствием рассматриваются.

UPDATE: монитор сети уже закомичен.

Ликбез по Boost.Preprocessor

Часто приходится слышать вздыхания коллег и вопросы "Почему так и зачем?" при виде например такого:

#define BOOST_FUSION_ADAPT_STRUCT(name, bseq)                       \
    BOOST_FUSION_ADAPT_STRUCT_I(                                    \
        name, BOOST_PP_CAT(BOOST_FUSION_ADAPT_STRUCT_X bseq, 0))    \
    /***/

#define BOOST_FUSION_ADAPT_STRUCT_X(x, y)    \
    ((x, y)) BOOST_FUSION_ADAPT_STRUCT_Y
#define BOOST_FUSION_ADAPT_STRUCT_Y(x, y)    \
    ((x, y)) BOOST_FUSION_ADAPT_STRUCT_X
#define BOOST_FUSION_ADAPT_STRUCT_X0
#define BOOST_FUSION_ADAPT_STRUCT_Y0

Я же начинаю грустить с мыслями "ипать-колотить, ну тут же всё просто!"...

Поэтому, дабы разбавить свой залежавшийся блог свежачком, я решил написать более-менее подробный ликбез о простом, а именно о Boost.Preprocessor.
Приведённый пример (boost/fusion/adapted/struct/adapt_struct.hpp) я разберу в конце статьи.

Lisp и real-time

Как-то раз коллега мне сказал: "на Лиспе ты реал-тайм систему не напишешь". Ответить было нечего, да. Но Гугель указал мне на Real-time programming in Common Lisp. Качебельная копия была обнаружена в ed2k.

О чём там, собственно-то...

Nouveau на FreeBSD

В /usr/ports/UPDATING заметил следующее:

20090801:
AFFECTS: users of x11-drivers/xf86-video-nouveau
AUTHOR: rnoland@FreeBSD.org

An updated libdrm and xf86-video-nouveau have been committed.  These
update the API version to 0.0.14 and if you are using DRM you will need
to update your kernel patch.  See pkg-message in xf86-video-nouveau for
details.

Будучи пользователем amd64, nv и GeForce 9600GT скорость прокрутки в терминале просто убивает, и поэтому я, сломя голову, понёсся ставить nouveau.