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

Да, условия жесткие.

Есть еще вариант: в каждом потоке должен быть свой менеджер памяти с собственным NEW и сброщиком. Это легко сделать, залинковав Kernel в DLL и создавая параллельный поток в DLL. Правда, это решение очень плохо масштабируется: чтобы создать 10 параллельных потоков, нужно создать 10 разных DLL.

Зато если подключить еще модуль Services и в параллельной DLL запустить кооперативную многозадачность, то чем вам не серверный вариант?