[prog.thougths] Попытка спроектировать механизм взаимодействия процессов на одной ноде через shared memory по принципу single-producer/multi-consumers

С конца прошлой недели занимаюсь проектированием механизма, посредством которого процесс-producer смог бы передавать через shared memory информацию одному или нескольким процессам-consumer-ам. Вроде бы придумалось какое-то решение, которое выглядит рабочим. Данный пост является попыткой еще одной проверки этого решения: если получится упомянутый механизм внятно описать словами, то есть хорошая вероятность, что он будет воплощен в коде.

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

В общем, всех заинтересовавшихся приглашаю под кат.

[prog.thoughts] И снова на тему исключений. На этот раз с подачи Вальтера Брайта

На HackerNews появился и обсуждается плач Ярославны Вальтера Брайта на тему исключений. Он там перечислил с десяток причин своей нелюбви к исключениям. Желающие могут ознакомиться сами.

Я же выделю два пункта из списка Брайта:

5. it is hard to write exception-safe code

6. very few understand how to write exception-safe code

Уже многократно говорил в своем блоге, но вынужден повторить еще раз: меры по написанию надежного и устойчивого кода в присутствии исключений точно такие же, как и при использовании кодов возврата.

Поскольку причина проблем в том, что происходит преждевременный выход из текущего скоупа и в коде нарушаются инварианты. Т.е. либо мы не освободили какие-то ресурсы, либо не закончили какую-то операцию, либо наши данные остались в несогласованном состоянии. Происходит ли выход из-за throw или из-за return-а -- не суть важно.

Еще раз: причина выхода из скоупа не важна, важно то, что мы куда-то вылетаем не доведя свою текущую цепочку действий до логического завершения.

И, как показывает практика, у многих программистов (включая меня самого) не очень хорошо с предсказанием последствий такого преждевременного выхода. В этом-то как раз и есть корень зла. Мы, люди, не особо хорошо справляемся с перебором возможных вариантов "а что, если здесь случится какая-то херня?" Это и есть основополагающая штука. А не throw, return или goto err.

У хейтеров исключений существует иллюзия о том, что если они будут писать код в стиле:

r = do_something();
if(-1 == r) {
  revert_changes();
  return -1;
}

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

По моим наблюдениям это, мягко говоря, не так.

Во-первых, большинство программистов очень плохо справляется с написанием кода, в котором требуется скрупулезное внимание к деталям. Плюс написанный в таком стиле код запросто может стать слишком объемным. Пример можно увидеть вот в этом моем посте шестилетней давности. А объем кода -- это дополнительные трудозатраты при сопровождении. Потребовалось добавить какую-то операцию, требующую отката в случае ошибки, и... И нужно вручную просматривать и модифицировать все места, в которых этот откат может потребоваться.

Да, я знаю, что идиома goto err сильно облегчает жизнь. Но это именно что средство для уменьшения боли, а не ее устранения.

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

Так что не буду спорить со всем перечнем претензий Брайта к исключениям, но вот эти два пункта -- это явно какая-то херня. При всем моем уважении к тов.Брайту.