Добрый день!
есть проблема, нужно в цикле создавать потоки, не больше 100 штук, при выполнении кода, прога зависает:


sleep должен слипить текущий поток(т.е. с которого его вызывали), почему он слипит все потоки ???
как реализовать ограничение ?

а не зависала бы - выдала бы StackOverflow. 
Судя по коду - там бесконечная рекурсия возникает. То есть, при вызове CreateThread 10000 раз вызывается она же. И там тоже самое. И так до бесконечности.
Не ясно, где меняется ThreadQty. 


почему все?
Текущий, который скорее всего и есть MainThread. C учетом того, что Delphi всю визуализацию делает в основном потоке - это более чем естественно. Но опять-таки, не ясно с ThreadQty.

Добавлено через 5 минут и 8 секунд
Чуть добавлю:
из-за рекурсивного бесконечного вызова процедуры приостанавливается выборка сообщений из очереди. Поэтому приложение и "зависает". И слипы тут ни при чем. Но включение в код Application.ProcessMesssages ничего хорошего не даст - просто до StackOverflow придется подождать подольше 

Существует ли в Windows ограничение в 2000 потоков на каждый процесс на самом деле? :

kami, поток сам себя убивает, с этим нет проблем, время работы потока в среднем 10мс.
с ThreadQty все нормально, это счетчик потоков, при создании потока +1, освобождении -1

почему все ? потому что прога зависает)
сказал уснуть гл.потоку, а уснули, по видимому, все =(

Добавлено через 3 минуты и 21 секунду
CodeMonkey, =) надо мне много потоков, сеть сканить гораздо быстрее получается!)

Добавлено через 4 минуты и 20 секунд
CodeMonkey, на шарпе/вб все нормально слипится. мне нужно на дельфе написать

В чем выражается это зависание?
Если в том, что не реагирует на мышь и клавиатуру, то еще раз повторюсь - это нормально. Потому что вы не обратили внимание на первую часть моего поста: у вас в коде БЕСКОНЕЧНАЯ РЕКУРСИЯ, лочащая основной поток.

kami, я не говорил, что это бесконечная рекурсия)
>поток сам себя убивает, с этим нет проблем, время работы потока в среднем 10мс


Это сообщение отредактировал(а) uranpro - 13.7.2009, 18:08

а я и не говорил, что это сказали вы. И говорил я за первоначальный код.



Добавлено через 1 минуту и 14 секунд
Где выход из этой рекурсии?
Я его не наблюдаю.

kami, я видимо плохо объяснил) 
строками

я хотел показать, что определил свойства и методы, с ними все ок.

а цикл в др. методе

Это сообщение отредактировал(а) uranpro - 13.7.2009, 18:13

ну дык... из кода этого-то не видно. Ограничил бы цикл begin-end ом, было бы понятнее.

Теперь вроде ясно.
Итак.
Исходная процедура ждет, пока не ликвидируется какой-нибудь поток, бо их количество стало больше критического.

Обратим внимание, что этот цикл не предполагает обработку сообщения, он просто ЖДЕТ.

Один из потоков закончил свою работу и хочет удалиться (но пока присутствует!!!)
Пытается сообщить об этом основной программе:

В Delphi метод Synchronize действует через отправку сообщения основному потоку, и ожидает, пока это сообщение (и содержимое метода Synchronize) не будет отработано.

Смотрим, что получилось:
основной поток в бесконечном цикле, не предполагающем обработку сообщений.
Дополнительный поток перед завершением отправил сообщение и ждет, пока главный поток выполнит его метод синхронизации. 
Цейнтнот, однако:
один не может, а второй ожидает окончания этого "не может". И конца и края их ожиданию не видно...

Добавлено через 4 минуты и 17 секунд
Предлагаю:
вместо Synchronize использовать отправку основному потоку сообщения через PostMessage, что ликвидирует задержки и развяжет потоки друг от друга.
Ограничение:
в обработчике этого сообщения нельзя будет использовать никакие ссылки и переменные, содержащие созданные TThread-ы

Добавлено через 13 минут и 38 секунд
второй вариант:
вместо Sleep поставить Application.ProcessMessages.
Но не советовал бы - навскидку не скажу, но были у меня какие-то трудноуловимые заморочки, связанные с Application.ProcessMessages в многопоточном приложении.

kami, Спасибо! я-то думал))

Быстрее всего сеть сканить в асинхронном режиме числом потоков, близким к числу процессоров.

хммм