Станислав Макаров

https://en.wikipedia.org/wiki/Covariance_and_contr...

For example, in C#, if Cat is a subtype of Animal, then:

• IEnumerable<Cat> is a subtype of IEnumerable<Animal>. The subtyping is preserved because IEnumerable<T> is covariant on T.
  
• Action<Animal> is a subtype of Action<Cat>. The subtyping is reversed because Action<T> is contravariant on T.
  

Даже не знаю, что добавить.

В этом же примере всё и написано, чуть выше. Цитирую:

// Set up the variables that receive the result of the asynchronous
// operation. The error code is set to would_block to signal that the
// operation is incomplete. Asio guarantees that its asynchronous
// operations will never fail with would_block, so any other value in
// ec indicates completion.
ec = boost::asio::error::would_block;
std::size_t length = 0;

Обратите внимание на "so any other value in ec indicates completion". Нам показывают, что начальное значение ec выставляется в would_block и используется как маркер того, что мы ЕЩЁ ничего не записали в переменную ec в обработчике handle_receive. Иными словами, как маркер того, что handle_receive ещё не выполнился. Когда выполнится - то, согласно интерфейсу Asio, в него прилетит что-либо, отличное от would_block, что и будет им записано в ec. Это и будет условием выхода из цикла.

Цикл здесь организован, чтобы дождаться выполнения конкретно асинхронной операции чтения.
Вам может показаться, что асинхронная операция здесь запускается только одна, но это не так, ведь есть ещё срабатывание таймера deadline_. Из чего можно заключить, что каждый вызов run_once может запустить либо обработчик handle_receive, либо check_deadline (напомню, что run_once прокачивает только один вызов какого-либо обработчика в очереди).

Предлагаю изучить вот этот проект: https://github.com/kbladin/KalleWheel
Апишки ищите тут: https://developer.adobe.com/console/servicesandapis#

Инструмент для вашей задачи - системное версионирование, введённое в SQL:2011, ищите "system-period temporal tables" или "system-versioned tables".

К сожалению ещё не все СУБД его поддерживают, насчёт MySQL не уверен. А вот MariaDB вроде умела.

Ну видимо потому что второму потоку не удалось захватить блокировку, он пошёл в ветку else и, после вывода сообщения, завершил свою работу, т.к. в теле функции Run больше нет инструкций.

Странно, что вы это спрашиваете, если писали этот код.

• https://github.com
  
• https://portal.azure.com
  
• https://www.tradingview.com (у нас Реакт, но фронтэнд весьма и весьма немаленький)
  
• веб-версия Экселя тоже немаленькая
  

Это я вам дал примеры БОЛЬШИХ веб-приложений. "Энтерпрайзные" в пример привести сложно, потому что обычно это значит "внутренние" или "ориентированные на конкретный тип бизнеса". Впрочем, какая разница, если речь идёт об оценке сложности.

Какая ОС? Результат вызова yarn global bin в PATH добавлен? Если нет, читайте инструкцию по ссылке.

если проверка прошла, то обе выполнятся

Кто сказал что СУБД позволит выполнить обе транзакции с одними и теми же исходными данными?
Если обе транзакции начали исполняться параллельно, прочитали одни и те же данные, и пытаются их перезаписать, как СУБД будет себя вести? Позволит ли она вообще отработать обеим транзакциям? Или одна их них подождёт, пока не закончит работу другая? Вопрос гораздо интереснее, чем кажется. И, что самое главное, неглупые люди уже подумали над ним. Очень хорошо подумали.

В доках постгреса написано ещё лучше.

Или лучше каждый раз пересчитыапть из истории?

Запаритесь пересчитывать, это не масштабируется, сложность расчёта будет всё время расти. Если считаете, что можете накосячить с текущим балансом - сделайте возможность его пересчёта согласно истории пополнений/трат. Это называется денормализованными данными. Это один из тех случаев, когда оправдано применение хранимых процедур для актуализации таких данных. Т.е. вместо непосредственной записи одновременно и в историю пополнений/трат и в актуальный баланс прямо из приложения, вы вместо этого вызываете хранимую процедуру, которая атомарно как пишет новую операцию - это ваши основные данные - так и меняет нужным образом ваши денормализованные данные - т.е. ваш баланс. Заодно в этой же хранимке можно дополнительно проверить возможность списания. Это решение не очень хорошо масштабируется, и вообще хранимки это антипаттерн для современных модных-молодёжных распределённых приложений, но судя по вашим вопросам врядли вы отвечаете за разработку сервиса, где таких списаний десятки тысяч в секунду, так что вам хватит.

Вот на SO ещё предлагают много решений этой классической проблемы, ни одно из которых не является идеальным и лучшим для всех ситуаций.

https://wiki.gtanet.work/index.php?title=OOP_Scripting - вот это не подойдёт?

Никакой религии в этом вопросе нет и быть не может. Есть вполне конкретные правила, когда писать типы весьма полезно.

Если вы НЕ указываете тип, и рассчитываете на автовывод, то значит вам нужен не какой-то конкретный тип, а ТАКОЙ ЖЕ, КАК И... где-то ещё. Например, такой-же-как тип константы или такой-же-как тип возвращаемого значения функции. Иными словами, если я пишу:
const id = findIdByName("abc");
то мне не так важно, какой конкретно тип будет иметь id, мне важно чтобы это был тип возвращаемого значения функции "findIdByName". Для меня это приоритетно. Более того, если в какой-то момент тип возвращаемого значения у этой функции поменяется, то этот код продолжить компилироваться и, вероятно, даже РАБОТАТЬ (это зависит уже от того, что мы потом собираемся делать с id).

Совершенно противоположная ситуация - интерфейсы. В широком смысле. Интерфейсы функций, интерфейсы классов, интерфейсы в смысле типов данных, создаваемых с помощью "interface". Особенно если эту функцию/класс/интерфейс использует много кто ещё. Тогда наоборот, вам НЕЛЬЗЯ допустить, чтобы типы параметров или тип возвращаемого значения просто так поменялись. Это вдвойне важно, если вы пишите библиотеку и речь идёт о её публичном интерфейсе - любое изменение интерфейса тогда должно подкрепляться версионированием (например, семантическим). Вы не можете просто так, тем более по недосмотру, вместо числа начать возвращать из функции строку - вы сломаете ваших клиентов, причём даже не знаете как и где.

Помимо того, что предложил Андрей Гаврилов , вам ещё нужно при заливке или после заливки объектов выставлять им ACL так, чтобы у группы Everyone (public access) были права Read. Скорее всего, при дефолтных настройках у вас не выставляется это право доступа.