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

дело явно не в сереализуемости. на проекте который развивался на протяжении 15 лет вполне логично увидеть какие-то вещи, которые не трогали очень долгое время. concurrency если я правильно помню появился примерно в 16 релизе, это около 2013 года. Скорее всего многие люди могли не трогать отдельные участки кода и это нормально. Что не нормально - когда опытный вроде чувак трогает код, но не ставит конкарренси опции для ets которая используется почти для всего.

Я тут наверно не в курсе положения с этими флагами. От какого конкретно кейса они защищают?

они не защищают от чего-либо, они улучшают конкурентный доступ к ets если у тебя много писателей/читателей

Не знаю как сейчас, но несколько лет назад проскакивал докладец о том как разные опции конкарренси влияют на производительность разных ets.

И там весьма неочевидные вещи местами.

ну там было типа "не стоит ставить read_concurrency" если у тебя много записи в таблицу и наоборот

Это как раз очевидно :)

т.к. с этими опциями у таблиц есть какие-то "режимы работы" и переключаться между режимом записи и чтения дорого

при отсутствии write_concurrency у тебя берётся эксклюзив лок на всю таблицу

read + write concurrency можно комбинировать вместе

намекаешь что это норм?

Что норм?

Комбинаций типов ets и флагов много, и некоторые из этих комбинаций имеют неочевидные особенности работы.

Навскидку я не скажу точно. Но суть как всегда в том, что нужно проверять и тестировать.

этот доклад или более свежий есть? https://www.youtube.com/watch?v=v0EcMi_gc_0

Да, он. Не помню чтобы было что-то свежее

Ну свежее только что в ordered_set теперь write_concurency работает, начиная с 22

Ну ты жжешь :)


Го уже больше 10 лет

Расту примерно столько же, собсна