Средства и методы разработки

Я видел одно изделие, где если пульт дать, условно, обезьяне и нажимать кнопки быстро-быстро, то там таки переполнялись очереди. Не из-за непосредственно клавиш. Из-за того, что событие нажатия клавиши порождало большую цепочку других событий, и так рекурсивно. И какое-то уже важное событие (а не факт нажатия клавиши) не помещалось в очередь. Куда-то в логи писалось "queue overflow...", а дальше всё стопорилось. Подумав головой вообще достаточно легко прийти к факту, что "лавина событий" возможна _всегда_, когда в процессе обработки одного события генерируется более одного (другого типа) события попадающих в конечном счёте в ту же очередь (т.е. рекурсия). И будет ли система погребена этой лавиной аналитически оценить достаточно сложно, если вообще не невозможно. Проблема примерно такого же уровня, как с оценкой необходимой глубины стека. Можно зарезервировать огромное избыточное количество памяти и по прежнему не иметь гарантии, что однажды не наступит переполнение (гарантию можно получить, только испытав программу всеми возможными комбинациями событий, пройдя по всем веткам алгоритма с любыми возможными аргументами -- что фактически невозможно). Но обычно экономика накладывает своё ограничение и начинается кроилово, глубину стека уменьшают до предельно минимально возможной, как и размер очередей событий. Кроилово неизбежно ведёт к попадалову. Ввиду сказанного, на мой взгляд построение системы в общем случае (я понимаю, что существуют частные случаи, когда лавина событий невозможна) только и исключительно на очередях сообщений -- очень плохая затея. В простых случаях можно оценить риски и прийти к выводу, что в имеющейся архитектуре системы "лавина" невозможна (события не умножаются или нет рекурсий, или их глубина чётко ограничена и вычислима), но когда система достаточно большая и сложная -- невозможно её анализировать и очень сложно изменять. Я уже писал, что рекурсию можно разорвать введением понятия "атомарных" событий, которые либо произошли, либо нет. Такие события не могут быть помещены в очередь несколько раз подряд, и не могут нести ассоциированной с ними информации. Атомарные события лучше реализуются на приоритетной очереди, но может быть использована и обычная очередь сообщений, если отдельно где-то отмечать, что такое-то событие уже присутствует в очереди или извлечено. Можно использовать event flags в ITRON-подобных ОС. А передача данных ассоциированных с атомарными событиями может осуществляться через отдельные, специфичные для конкретного типа событий, FIFO-буфера (pipe), Go-каналы, отдельные очереди сообщений. Если это нужно. Потому, что на самом деле основная масса событий в системе не требует передачи дополнительных данных.