Для этого события с автосбросом не нужны. Серьёзно, забей, плз.
Вот повезло, что я пишу с телефона и мне неудобно цитировать твои же предыдущие ответы. Кратко - ты сам предлагал их использовать две страницы назад для решения задачи на эвентах. Да пожалуйста, можно и с ручным сбросом, только, чтобы не все потоки просыпались при вставке в очередь. Ты говорил, что это просто, но решения и даже ссылки до сих пор нет. Расцениваю как слив.
Что значит "уязвимы"? Для рядового кодера вероятность накосячить с cv на порядок меньше. Мне даже сложно представить ситуацию, когда гонка или дэдлок буду прямо неочевидны. Если ты сможешь привести буду рад. Про эвенты легко могу привести. У них даже в msdn в примере работы с com-портом была гонка. Нативная реализации блокирующей очереди на эвентах страдает от "кражи" события другим потоком, что для для многих джунов весьма неочевидно.
Если для тебя это не показатель качества процесса, то прости, что побеспокоил.
Мне вообще не особо понятно как мы перешли от обсуждения кривости архитектуры и примера с событиями к качеству и рискам. Ещё раз повторюсь, что на кривой архитектуре можно построить надёжное приложение (обычно подперев изрядным количеством костылей). Верно и обратное - на "совершенном" api построить нечто очень глючное. Короче смысла обсуждать этот аспект я вообще не вижу.
Нормальным пользователям(не IT-гикам) линь даром не нужен.
Вот из-за представления о нем как игрушке для гиков он так плохо распространен на ПК. На само деле многие рядовые юзеры живут на убунте ничуть не хуже, чем на Винде. Стереотипное мышление + it-неграмотность.
В первый раз вижу, чтобы жирность расценивалась как преимущество.
Из WinApi можно 80% всего выкинуть без ущерба функциональности. Там большая часть для обратной совместимости, а если покопать внутри, то это просто обертки.
