Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Наткнулся на просторах "этих ваших интернетов" с следующей подписью:
"DDoS инструмент, который позволит вам наказать обидчиков, либо протестировать конкурентов) Вам нужно в коде изменить example com -> на свой сайт для атаки. Скоро опубликую IP DDoS Tool)"
Это может сработать, если у вас, например, Coffee Lake i7, и вы по 100Base-T подключены к машине с Celeron 333 за соседним столом, и на ней, под уравлением Windows 98, работает Apache 1.3 с веб-сайтом...
Да, желательно, чтобы на пути сигнала не было никаких маршрутизаторов, которые могут зависнуть от частых запросов.
Хотя это может сработать и в более общих условиях, если сервер очень тормозной: слабый процессор или медленная база данных. «Медленная база данных» может означать, что запрос содержит 100500 джойнов, индексы отсутствуют и т. п.
Есть такие сайты, которые лучше вообще не открывать: каждый запрос они обрабатывают по 30 секунд. Такой сайт можно положить с помощью браузера и кнопки "F5"
Запустите на всех компьютерах в кабинете информатике и сверните - может, не заметят (для этого переименуйте файл в SystemCheck.py). Дома запустите на своем компе и на папином ноутбуке. Попросите запустить друга.
Погуглил. «pudo ser» с испанского переводится как «может быть», однако, на некоторых сайтах встречается опечатка «pydo ser». То ли диалектное написание (есть же всякие малораспространённые языки вроде каталанского, арагонского, галисийского, окситанского), то ли авторы малограмотные.
Там в основном разница в произношении (кубинцы, например, глотают «s» перед согласными и в конце слова, а также глотают «d» между гласными). А также бывают диалектные слова и выражения, которые в других регионах не употребляются. Ну как подъезд и парадная.
Гораздо хуже внутри самой Испании: в Арагоне, в Валенсии, в Каталонии, в Астурии, в Галисии могут говорить не на кастильском испанском, а на местных языках, которые без переводчика житель Кастилии не поймёт.
Много арагонские сервы,
Малость евросоюзные смерды.
Много раб принимает свою участь,
Малость лютеранин начинает работать лучше.
Много мусульман заставляют работать в поле,
Много лютеран дубинками гонят в неволю.
Зачем прогоняем защитников ветхозаветных законов?
Много лютеранин сгорит вместе со своим городом.
Забавно, что эта хуйня кроме того сожрет все доступные пиды и распидорасит систему. Гораздо более вероятно, нежели чем уложит цель. Ну только если там не php-cgi, конечно.
1. Да.
2. В том, что два потока не работают одновременно. Если первый завис на IO, то запускается второй. Одновременно не работают. Только по очереди. Во время остановки одного и запуска другого происходит полный happens before: ставятся заборы, и процессор флашит буфера. Все, что сделано в первом потоке, уже видно во втором. Потому вручную ничего синхронизировать не надо.
* Чтобы блокирующий синхронный код писать без лапши
* Чтобы блокирующий синхронный код писать без лапши
* Чтобы блокирующий синхронный код писать без лапши
Перформнса ни какого, просто красота.
> что с requests тоже не поможет
Напротив: я написал, что requirests это io.
Пока один спит на IO миллион лет, другой поток хуячит.
Что не понятно?
В результате выполнения этого кода на сервер example.com будут последовательно совершены 100 запросов, каждый из которых будет выполнен только после того, как завершится (клиент полностью получит и распарсит ответ) предыдущий.
def getHuj():
requests.get("http://example.com")
for _ in range(100):
threading.Thread(target=getHuj).start()
time.sleep(10) # чтобы программа не завершилась досрочно
В результате выполнения этого кода на сервер example.com придут 100 параллельных, одновременных запросов (NB: вместо time.sleep() в конце надо сделать join() по всем тредам, но это лишнее усложнение реального примера).
В приведённом тобой примере поток, скорее всего, будет упираться не в IO, а как раз в CPU. Потому что диски сейчас пошли быстрые и умные, со всякими там кэшами, и большую часть времени поток будет байты в буферах гонять и сисколлы дёргать.
Справедливости ради, какое-то увеличение производительности, скорее всего, будет. Или не будет, если оверхед от переключения потоков (а это весьма тяжёлая вжопурация) перевесит.
Широко известно, что на одном ядре процессора в один момент времени может выполняться только одна инструкция из одного потока. Чтобы на компьютере мог работать охулион программ с охулиардом потоков, в реальном мире применяется так называемая «вытесняющая многозадачность»: операционная система составляет список всех потоков, запускает первый, ждёт N миллисекунд (это называется «квант времени»), останавливает первый, запускает второй, ждёт N миллисекунд, останавливает второй — и так далее (там ещё есть всякие приоритеты, прерывания, состояния потоков и прочая муть — но оно не нужно). В результате у пользователя создаётся впечатление, что все потоки работают «одновременно» — профит!
Теперь пусть есть два потока, A и B, и одноядерный процессор («GIL» в «Python» как раз его эмулирует: в один момент времени в пределах одного интерпретатора может работать только один поток, вне зависимости от количества ядер процессора). Запускается поток A. Этот поток посылает на example.com GET-запрос. Если он реализован блокирующим способом — потоку нужно дождаться, пока с сервера придёт ответ, то есть ничего не делать несколько десятков-сотен миллисекунд. В это время, пока поток A ничего не делает, ожидая ответ от сервера, включается поток B и может спокойно делать, что ему требуется. Таким образом, поток B получает дополнительные кванты времени, а поток A «упирается в IO».
Теперь представим, что поток A считает число «Пи» до триллионного знака. Все выделенные ему операционной системой N миллисекунд он будет гонять байтики в процессоре, и ждать не собирается. В результате поток B будет получать кванты времени только по очереди с A. На процессорах с несколькими ядрами в таком режиме работы будет загружено только одно ядро (из-за «GIL»).
Спасибо, понятно. Гость только с толку сбил своим «IO».
Получается отличие от JS в том, что в JS пока один «поток» не завершится, другой не сможет стартовать, а игил даёт по чуть-чуть времени по очереди.
Да, как и в «asyncio». Это называется «кооперативная многозадачность» — когда один поток отдаёт управление другим тогда, когда сам захочет.
И небольшая поправочка: время для потоков из «threading» даёт не «ИГИЛ», а операционная система. «GIL» лишь гарантирует, что в одном интерпретаторе «Python» одновременно будет выполняться только один поток, вне зависимости от количества ядер процессора.
А, я попутал. В «asyncio» никаких тредов нет, именно поэтому я за это они в «gevent»/«eventlet»/etc есть, вернее, не треды, а гринтреды. И там уже классическая кооперативная многозадачность, в которой ОС не участвует.
В «threading» — обычные системные треды.
«GIL» — это, по сути, просто системный мьютекс. Чтобы тред из «threading» мог выполнять любой питоновский байткод (в пределах одного интерпретатора-процесса) — тред должен владеть этим мьютекстом.
Да, все так. Это системный мутекс, с помощью которого сипатон "стопает" все треды, кроме одного. По сути он просит шедулера операционки отъебаться от этих тредов
Асинкыо это копро-ротивная многозадачность, потому написав там sleep() можно навеки усыпить весь свой процесс.
А threading это сисемные слипы, многозадачность там вытесняющая, там можно спать.
Мне один древний программе расказывал, как под какой-то девайс типа спектура писал, и там было прерывание от модуля синхронизации развертки 50Hz или сколько там частота. Можно завязаться на такое вот
Там можно было и без прерывания спросить состояние луча через IO и сделать бизивейт (один хуй в ту пору все было однозадачное и без изменения частоты). Разумеется, если ты пишешь пошаговую стратегию, а не экшен
А там у чуваков это был чуть ли не единственный хертбит, так сказать.
Кстати, если ты хочешь оккупировать все ядрачистый изумру, то можешь использовать мультипроцессность
Процесс в прыщах едва-ли тяжелее потока, потому что в ядре разницы между потоками и процессами почти нет. Куча при форке копионрайтнется, так что даже память будет общая (пока ты туда чото не запишешь, тогда она скопируется, и видимо создастся новая страница и переключение станет чуть дороже тк будет трогаться TLB). Некоторые (старый апач например, постгря и постфикс) спокойно плодят кучу процессов и не паряца.
На винде все хуже, там у каждого процесса есть куча своих структур, и потоки рекомендуются.
У макх (ябло) вроде бы ситуация ближе к виндовой, там есть вроде бы отдельные потоки (но могу спизднуть)
>> Широко известно, что на одном ядре процессора в один момент времени может выполняться только одна инструкция из одного потока.
Почти. Уже на первом «Пентиуме» (P54) было два стула конвейера: «U-pipe» и «V-pipe». Могли одновременно исполняться две инструкции (одна проходила через «U-pipe», вторая — через «V-pipe»), если они не мешали друг другу, например, если они работали с разными регистрами, не задевая при этом флаги, не трогая EIP и не обращаясь к оперативке и к портам ввода-вывода. Там ещё какие-то ограничения были, «V-pipe» был неполноценным и умел исполнять не всё, поэтому распараллеливание инструкций было не таким частым событием.
Могли и с одним и тем же регистром работать, гуглить про Томасуло и его резерные станции)
Я бы изменил терминологию Госта: игил эмулирует не просто "один процессор" а то, что в СУБД называется "serialized access": то-есть все комманды выглядят так, словно бы они были выполнены СТРОГО последовательно
Ну либо надо говорить что он эмулирует один ОЧЕНЬ ПРОСТОЙ процессор БЕЗ параллельного выполнения
А, это винда своим окошком «прекращена работа…» напугала. На самом деле там «Unhandled exception at 0x00007FFHUJHUJHUJ (ucrtbase.dll) in python.exe: Fatal program exit requested.»
Да, костыли, которые не дадут положить весь инстанс одному дебичу с зажатой F5, наверняка есть. Но крайнюю хрупкость «апача» этим не исправить — он так сделан.
Кстати, чтобы побыстрее исчерпать количество доступных соединений, на сервере нужно:
1. Увеличить интервал keep-alive, чтобы ненужные соединения висели как можно дольше.
2. Либо использовать технологию «Comet». Это не средство, которое рекламировала «тётя Ася», а вечно открытое соединение для питушни реального времени вроде мессенджеров: https://ru.wikipedia.org/wiki/Comet_(программирование)
Если за «Апачем» много сайтов, которые используют первое и/или второе, положить их будет легче.
> Основной баг как раз в вашем рнр коде, как вы сами и написали рекурсивный вызов, который и так очевиден, без анализа исходников.
В комментах типичная идейная пыхомакака, которая уверена, что "РНР" на самом деле идеален, это все остальные ничиво нипанимают и не умеют правильно писать на "РНР".
Не так давно я ставил себе сборку «Скайрима» и столкнулся с интересным багром: штатно там запускается файл «TESV.exe», который запускает файл «SKSE.exe», который запускает файл «Skyrim.exe» (первый — простая обёртка-запускатор, второй — хуйня, которая расширяет скриптовый движок «Скайрима», третий — сам «Скайрим»). А вот при попытке запустить всё это добро из менеджера модов случился багор: «TESV.exe» запускал «SKSE.exe», а «SKSE.exe» запускал… «TESV.exe»! В результате на экране начала вылезать и тут же исчезать туева хуча консольных окошек (какой-то из этих бинарников оказался с «Subsystem: Console»), мгновенно срывавших фокус. К тому, ничего с файлами сделать было нельзя — мол, используются, неможно их удалять. Исправил путём применения крутой утилиты под названием «Unlocker», переименовав один из файлов в хуйню.
Вообще руснявая игровая ракота это просто невообразимый пиздец, вон там тытруба в предлагает посмотреть "даэдрическая броня на 1 уровне", а на самом деле какой-то малец советует кастовать файрболл в стену до 90 уровня а потом поллора обойти ради ингридиентов. А русня даже не жалуется на это.
Именно поэтому я за «DOS». Стек не больше 64К, зато его можно растягивать неограниченно, затирая данные и код своей программы (потому что он растёт вниз).
А на example.com, оказывается, повесили тестовую страничку с таким содержимым:
________________________________________ ____________________________
Example Domain
This domain is for use in illustrative examples in documents. You may use this domain in literature without prior coordination or asking for permission.
Читаем RFC 2606. Там есть глава про домены второго уровня.
3. Reserved Example Second Level Domain Names
The Internet Assigned Numbers Authority (IANA) also currently has the
following second level domain names reserved which can be used as
examples.
example.com
example.net
example.org
Хотя это может сработать и в более общих условиях, если сервер очень тормозной: слабый процессор или медленная база данных. «Медленная база данных» может означать, что запрос содержит 100500 джойнов, индексы отсутствуют и т. п.
Про базу согласен.
Есть такие сайты, которые лучше вообще не открывать: каждый запрос они обрабатывают по 30 секунд. Такой сайт можно положить с помощью браузера и кнопки "F5"
"Пидосер"
Гораздо хуже внутри самой Испании: в Арагоне, в Валенсии, в Каталонии, в Астурии, в Галисии могут говорить не на кастильском испанском, а на местных языках, которые без переводчика житель Кастилии не поймёт.
Я в детстве зарядил трехлитровую банку воды от Кашпировского, которого показывали по телевизору.
У него есть RS-485, по нему можно считать показания. Хз, что мне делать с этой информацией.
Будет конечно немного похоже на комбайн для завязывания шнурков
Показалось, «аргонианского».
Малость евросоюзные смерды.
Много раб принимает свою участь,
Малость лютеранин начинает работать лучше.
Много мусульман заставляют работать в поле,
Много лютеран дубинками гонят в неволю.
Зачем прогоняем защитников ветхозаветных законов?
Много лютеранин сгорит вместе со своим городом.
Значит, всё-таки задачи нужно как-то планировать: ограничивать количество итераций или разбивать паузами.
Тут, блять, всего 3 строчки. На что там можно было 6 версий просрать?
Меня ещё забавляет, что чувак не осилил аргументы командной строки. Нужен другой URL? Иди и руками меняй, сука!
Починил.
> os.fork()
Лол, это типа сам себе сделал Deny of Service форк-бомбой?
2. В том, что два потока не работают одновременно. Если первый завис на IO, то запускается второй. Одновременно не работают. Только по очереди. Во время остановки одного и запуска другого происходит полный happens before: ставятся заборы, и процессор флашит буфера. Все, что сделано в первом потоке, уже видно во втором. Потому вручную ничего синхронизировать не надо.
Ты можешь увидеть кусочек данных, или даже то, чего не может быть, потому что процессору можно переупорядочить выполнение.
IO происходит в нативном коде, и питоновую память он не тронет. А когда он ложится спать, он явно ставит забор
Многопоточность бывает для двух задач:
* Чтобы блокирующий синхронный код писать без лапши
* Чтобы заюзать все ядра
Для первой задачи threading ок. Для второй -- нет
Но так как в языке нет семантики для синронизации потоков, я хз как это можно избежаьть
Ну можно сделать from __future__ import real_threads и только тогда включать труъ треды.
* Чтобы блокирующий синхронный код писать без лапши
* Чтобы блокирующий синхронный код писать без лапши
Перформнса ни какого, просто красота.
> что с requests тоже не поможет
Напротив: я написал, что requirests это io.
Пока один спит на IO миллион лет, другой поток хуячит.
Что не понятно?
В шапке этого треда приведён же... HTTP запросы исполняются параллельно - пока один тред ждёт ответа от сети, другой может поделать что-то ещё.
В результате выполнения этого кода на сервер example.com будут последовательно совершены 100 запросов, каждый из которых будет выполнен только после того, как завершится (клиент полностью получит и распарсит ответ) предыдущий.
В результате выполнения этого кода на сервер example.com придут 100 параллельных, одновременных запросов (NB: вместо time.sleep() в конце надо сделать join() по всем тредам, но это лишнее усложнение реального примера).
> Пока один спит на IO миллион лет, другой поток хуячит.
Так чем мой пример с 100 файлами отличается? Это не спячка на IO? Не понимаю при чем тут IO. Обычный Sleep не подойдёт?
Sleep должен прокатить за IO.
(ну и Sleep ещё)
Справедливости ради, какое-то увеличение производительности, скорее всего, будет. Или не будет, если оверхед от переключения потоков (а это весьма тяжёлая вжопурация) перевесит.
Ты можешь отключить буфер, и тогда оно будет писаться сразу на диск, и это будет медленее.
Наконец, ты можешь попросить ОС явно попросить диск зафлашить из его буфера (в ATA есть такие комманды) будет еще медленее.
Но если у тьебя рейд, то все зависит от того, какой у тебя рейд
А если у тебя SAN (с iscsi или фибра ченел) , то все зависит от
Короче, это админкины области и ебля, но в целом ты прав: писать на диск можно очень быстро
Теперь пусть есть два потока, A и B, и одноядерный процессор («GIL» в «Python» как раз его эмулирует: в один момент времени в пределах одного интерпретатора может работать только один поток, вне зависимости от количества ядер процессора). Запускается поток A. Этот поток посылает на example.com GET-запрос. Если он реализован блокирующим способом — потоку нужно дождаться, пока с сервера придёт ответ, то есть ничего не делать несколько десятков-сотен миллисекунд. В это время, пока поток A ничего не делает, ожидая ответ от сервера, включается поток B и может спокойно делать, что ему требуется. Таким образом, поток B получает дополнительные кванты времени, а поток A «упирается в IO».
Теперь представим, что поток A считает число «Пи» до триллионного знака. Все выделенные ему операционной системой N миллисекунд он будет гонять байтики в процессоре, и ждать не собирается. В результате поток B будет получать кванты времени только по очереди с A. На процессорах с несколькими ядрами в таком режиме работы будет загружено только одно ядро (из-за «GIL»).
Получается отличие от JS в том, что в JS пока один «поток» не завершится, другой не сможет стартовать, а игил даёт по чуть-чуть времени по очереди.
И небольшая поправочка: время для потоков из «threading» даёт не «ИГИЛ», а операционная система. «GIL» лишь гарантирует, что в одном интерпретаторе «Python» одновременно будет выполняться только один поток, вне зависимости от количества ядер процессора.
Разве не может ОС вытеснить один поток? Игил просто гарантирует, что второй поток сразу же остановится.
В «threading» — обычные системные треды.
«GIL» — это, по сути, просто системный мьютекс. Чтобы тред из «threading» мог выполнять любой питоновский байткод (в пределах одного интерпретатора-процесса) — тред должен владеть этим мьютекстом.
Асинкыо это копро-ротивная многозадачность, потому написав там sleep() можно навеки усыпить весь свой процесс.
А threading это сисемные слипы, многозадачность там вытесняющая, там можно спать.
+треды
У вас есть комп без хардварного таймера
Как там реализовать вытесняющую многозадачность?
На x86, например, можно поднять флаг трассировки, чтобы после каждой инструкции генерировалось прерывание.
Еще варианты?:)
Можно переключать задачи по прерываниям от разных устройств (возможно, придётся очень долго ждать).
А там у чуваков это был чуть ли не единственный хертбит, так сказать.
Правда придётся немного анлизировать код на наличие инструкций перехода.
Наплодил потоков, и смотришь с помощью procexp/windbg или ps/gdb какие есть потоки, какие стеки у них итд
Хотя устройство ОС я бы советовал изучать с помощью обычной сишечки, без прослоек
Процесс в прыщах едва-ли тяжелее потока, потому что в ядре разницы между потоками и процессами почти нет. Куча при форке копионрайтнется, так что даже память будет общая (пока ты туда чото не запишешь, тогда она скопируется, и видимо создастся новая страница и переключение станет чуть дороже тк будет трогаться TLB). Некоторые (старый апач например, постгря и постфикс) спокойно плодят кучу процессов и не паряца.
На винде все хуже, там у каждого процесса есть куча своих структур, и потоки рекомендуются.
У макх (ябло) вроде бы ситуация ближе к виндовой, там есть вроде бы отдельные потоки (но могу спизднуть)
Почти. Уже на первом «Пентиуме» (P54) было два стула конвейера: «U-pipe» и «V-pipe». Могли одновременно исполняться две инструкции (одна проходила через «U-pipe», вторая — через «V-pipe»), если они не мешали друг другу, например, если они работали с разными регистрами, не задевая при этом флаги, не трогая EIP и не обращаясь к оперативке и к портам ввода-вывода. Там ещё какие-то ограничения были, «V-pipe» был неполноценным и умел исполнять не всё, поэтому распараллеливание инструкций было не таким частым событием.
Я бы изменил терминологию Госта: игил эмулирует не просто "один процессор" а то, что в СУБД называется "serialized access": то-есть все комманды выглядят так, словно бы они были выполнены СТРОГО последовательно
Ну либо надо говорить что он эмулирует один ОЧЕНЬ ПРОСТОЙ процессор БЕЗ параллельного выполнения
https://www.enlight.ru/faq3d/articles/61.htm
Тут же вторая инструкция ожидает результата первой. Они объединяются в какую-то суперинструкцию?
После чего «python.exe» упал.
Какой багор )))
Тогда нужно верхнеуровнево сделать try, тогда багор, да.
а так напоминает синкуку конечно
в ту пору не думали, что будут такие мудаки
кстати, ограничить можно на уровне файрволла даже
1. Увеличить интервал keep-alive, чтобы ненужные соединения висели как можно дольше.
2. Либо использовать технологию «Comet». Это не средство, которое рекламировала «тётя Ася», а вечно открытое соединение для питушни реального времени вроде мессенджеров:
https://ru.wikipedia.org/wiki/Comet_(программирование)
Если за «Апачем» много сайтов, которые используют первое и/или второе, положить их будет легче.
В комментах типичная идейная пыхомакака, которая уверена, что "РНР" на самом деле идеален, это все остальные ничиво нипанимают и не умеют правильно писать на "РНР".
Так у меня же finally было!
except — неправильно.
С finally программа будет работать ОЧЕНЬ долго и стабильно.
Впрочем я когда-то (очень давно) умудрялся без перезагрузки прибивать эти процессы, когда был запущен невинный bat-файл
https://ideone.com/ge7FUw
Интересненько
https://ideone.com/t2C9nH
https://ideone.com/80ICnO
Что-то не пойму почему так памяти мало сожрано.
Может ещё аллокацию какую прикрутить чтобы в своп зашло.
Так ls же можно сделать.
Jan 11 20:23 .. -rw-rw-r-- 1 root root 28 Jan 11 20:23 prog.sh
https://www.youtube.com/watch?v=YD_8pxjr70o
Вообще руснявая игровая ракота это просто невообразимый пиздец, вон там тытруба в предлагает посмотреть "даэдрическая броня на 1 уровне", а на самом деле какой-то малец советует кастовать файрболл в стену до 90 уровня а потом поллора обойти ради ингридиентов. А русня даже не жалуется на это.
Тут их бесконечно много, ну пока стека хватит и http запросы успешно исполняются.
То ли дело жаба.
https://ideone.com/fork/ZDal8g
Это можно хоть на сервак деплоить.
________________________________________ ____________________________
Example Domain
This domain is for use in illustrative examples in documents. You may use this domain in literature without prior coordination or asking for permission.
More information...
________________________________________ ____________________________
Ссылка ведёт на https://www.iana.org/domains/reserved
Раньше по адресу example.com вроде сайтов не было.
Он ещё и ETag отправляет для отслеживания.
Domain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.iana.org
Registrar URL: http://res-dom.iana.org
Updated Date: 2019-08-14T07:04:41Z
Creation Date: 1995-08-14T04:00:00Z
Registry Expiry Date: 2020-08-13T04:00:00Z
Registrar: RESERVED-Internet Assigned Numbers Authority
Registrar IANA ID: 376
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone:
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET
Его еще и продлевать надо :))
Опять голоса в голове спорят?
это оъуегнно
А он вкладывал, наверное, зубами, и сунул туда голову
И теперь он тоже медведь.
Сколько это выдержит комп?
Не понимаю, на что он там сожрал 85(!) гигов виртуальной памяти. Стеки вроде мелкие.
Но один фиг 10150. Видимо в айдишники упирается.
Совсем нефиг делать в выходные? 🙂
Хотя, с NVMe питушнёй наверно не так долго ждать.
То есть «commited» (реальный прирост свопа или заём из оперативки) будет после первого доступа?
А зачем тогда при создании треда память резервируется, если не используется? Зачем? Зачем?