> -- Илья Ермаков писал(а):
> Ну, не надо так драматизировать  Тормозится исключительно обновление экрана, причем тут многопоточность? Потоки как работали, так и работают. Их назначение все же преимущественно не GUI, а вычисления либо серверные задачи.И Synchronize не годится для выделения памяти, т.к. время отклика его порядка десятков миллисекунд, а на выделение памяти уходят микросекунды.Проблема многопоточности серьезней, чем кажется на первый взгляд. Полгода назад, берясь за Active BlackBox, я тоже начал с таких штучек. Не заработало. Ключевая проблема - сборка мусора. Сборщик мусора, проходя по ссылкам, маркирует доступные объекты, изменяя их тег типа на нечетный. Таким образом, во время сборки мусора память в нецелостном состоянии. Многопоточное ядро знает все потоки и умеет их замораживать на этот период. Добавьте сюда то, что NEW не поддерживает повторную входимость. Без многопоточного ядра работать с потоками в ББ нельзя.По поводу обработки сообщений - попробую поглядеть, в чем там дело...

То что тормозит обновление экрана это мне было понятно с самого начала. Но в момент отображения поток "сливается" с основным потоком Blackbox (происходит синхронизация). Представьте себе, что поток обрабатывает критически важную информацию и в какой-то момент надо отобразить ее (довести до пользователя), а тут бах приходится ждать пока пользователь не закроет меню. И все ведь потоки  (если их несколько), которые захотят что-то отображать будут ожидать.

P.S. Если Blackbox был использован для управления крупнейшей ГЭС
(Unix вариант), я не думаю, что из-за меню останавливалась отображение критических параметров системы.

Поэтому должно быть Active BlackBox +  продуманная обработка очереди сообщений. И тогда получится хороший продукт.