Потоки.Как сделать по оптимальней.

Aspire
Начнем с того, что спорить мы начали не с этого. Вы привязались к тому, что не желаете лишний раз передавать управление системе вызывая функцию ioctlsocket, и приводите в свое оправдание, что мол это работает быстрее, но (даже при скромных подсчетах, навскидку, без какой либо вычислительной техники) получается, что Ваш метод съедает памяти у системы столько, что не выдерживает никакой критики. Я лишь хочу указать Вам на этот момент, а не на то как я это делаю. Что касается выбора сокетов. Существует подсистема event'ов, работает не айс, но работает. При малой модификации (написание своего кода, я не собираюсь сюда это выкладывать т.к. это 1. будет очень громоздко, 2. это то что писалось строго для коммерческого использования и не распространяется свободно) система начинает работать превосходно. С помощью асинхронной системы переадресации event'ов (это те самые переходники, о которых говорилось выше) достигается вызов ранее описанной функции с конкретными параметрами. Система асинхронная, т.е. каждый установленный event вызывает callback функцию. Отчасти event'ы опрашиваются в одном потоке в цикле с Wait For, но большая часть перехватывается у системы путем перехвата вызова системных функций из системных dll. Что еще не понятно. И еще. Я уже давно не пишу под стандартным WinAPI. Его функционал расширяется мною переписанным или дописанным кодом. Но это не мешает ссылаться на отдельные моменты в реализации, которыми некоторые злоупотребляют или не умеют пользоваться (не буду показывать пальцем, но в начале этого поста я уже это сделал).

 

max7C4, так что, в итоге ты имеешь WaitForXxx() вместо select(), как я и предположил выше. Ну и чего что необычного? Кста, в твоей реализации один поток?

Ну а про вышеописанные онанизм и танцы с бубном - думаю что этого ничего не понадобилось, если б ты воспользовался IOCP. И эта модель превосходно масштабируется на несколько потоков - всего-то надо отдать сокет какому-нить потоку.

Такой софт не имеет асма, работает на всех версиях винды и компилится в 64бит.

 

То что WaitForXX используется не для сокетов. А для тех event'ов, которые у меня перехватить не получилось. Если в очереди только socket events, то сама подсистема даже не вызывает WaitFor и организуется как цикл обработки сообщений в винде. А сообщения в очередь поступают со всех потоков приложения, а могут даже со всех приложений использующих (и не использующих) мой механизм.

Это зависит от загрузки и от начальной инициализации. Потоки создаются по мере загрузки системы (в случае обнуления счетчика загрузки создается новый поток обработки) и ограничены счетчиком потоков (в случае обнуления потоки создаваться не будут).

прикинь, а мое работает не только под винды, и все из-за того, что есть правильный интерфейс работы с системой, который скрывает особенности и все механизмы реализованы мной любимым

А кто сказал, что нет версии моего расширения для 64 бит.

 

max7C4, очень мутно всё это ты описываешь. Так как ты ожидаешь прихода данных на N открытых соединений?

 

У меня есть функция, которая все делает. Надоело уже тут распинаться. И я уже сказал, что я за пул потоков. Все. Пишите. А как я это делаю смотри в 23 посте (между первой и второй цитатами, если не нашел), а в двух словах, то жду когда они придут и мне об этом скажут.

 

s0larian Я же говорю, суровый чел... У него свои винапи... подозреваю, что даже нтапи..

 

У меня уже давно не WinAPI. Иначе бы нельзя было запускать код под другой ОС. Но я не понимаю что не понятного в системе асинхронных event'ов. Кто их генерирует? Или почему они поступают в очередь не весть откуда? Или как поток узнает что в очереди ждет event? Или вы не знаете как писать программы не опираясь на системный функционал или выйти за его пределы? Что допустим сложного в написании dll модуля, который экспортирует функцию? А что сложного в написании dll модуля, который не экспортирует функций, пока не пройдет инициализацию? А что сложного в написании такого модуля у которого имеется интерфейс полностью заменяющей все необходимое и умеющий работать с любой системой (но тут вроде бы все очевидно, сложность в объеме)? А что сложного в написании такого же модуля, но который может регенерировать или альтернативно линковать свои кусочки в динамической памяти? А что сложного в перехвате у системы вызова той или иной функции? Event это по сути реакция на то или иное событие в системе, но событие может генерироваться самой системой, а может и не генерироваться, но в любом случае будет проверка стоит ли его генерировать. Что сложного в анализе кода на эту проверку и динамическое преобразование этой функции (хотя тут тоже все очевидно, с таким анализом ваши Си програмки не справятся, ну или не справятся, до того, как Вы состаритесь. шучу. не обижайтесь.)? Написать код, который знает большое количество билдов и знает где какая проверка находится - это один из вариантов, но его придется активно расширять. А вот написать код, который более или менее автономно анализирует системные модули - это задача не тривиальная. Я не хочу тут расписывать все до мелочей. Можно и самому сообразить, как написать замену системному механизму. И я уже сказал за какую я реализацию. Пул потоков. Если конечно не хотите написать что-то очень сложное.

 

Это маразм, а не программирование. Нах это всё надо? Сколько в этом ошибок? Сколько это отлаживалось? Ломается на каждом service pack, не говоря об обновлённой OS? Понадобилось переписать с ноля для x86_64?

Смысла в этом не вижу.

Мы, похоже, говорим на разных языках. На дворе 2009 год, а ты переписываешь системные механизмы, не понимая ,что всё давно написано и отшлифовано в NT ветке - I/O completion ports.

Заканчиваем разговор тогда. Я буду заниматься разнаботкой логики своей проги, написанной на современном С++ (с STL и boost), а ты отлаживай свою кустарную систему асинхронных событий.

 

s0larian

Сорри, промахнулся. Это было к Aspire

 

я это уже давно все переписал. и просто этим пользуюсь. и все представьте работает и даже на Windows 7. а какая разница какой код генерировать (32 или 64). все уже написано за нас, но не для людей. а слепо верить тем, кто что-то написал - будешь задавать глупые вопросы типа "как сделать по оптимальней".