All streams
Search
Write a publication
Pull to refresh
9
0
Send message
Есть такой недочёт=) Приятно что хоть кто-то оставляет комментарии по делу…
2 — Я видел такой альтернативный вариант реализации. Тоже попробую. Там интересно посмотреть как будет обстоять дело с постановкой в очередь своих собственных сообщений и с выборкой их оттуда.
Да RegisterWaitForSingleObject тут бы подошла отлично если бы поддерживала сокеты. В целом идея отличная, сегодня её проверю. Спасибо! Насчёт пула — я не нашёл подходящего в стандартной библиотеке, к сожалению…
Я всё понимаю. Но опять таки. Исходник выложен только с той целью, что если какому-то хардкорщику из ряда системных программистов придётся столкнутся с асинхронной очередью в сокетах для него это будет подарок. Даже так как он есть. Этот топ нацелен на достаточно узкую, интересную и сложную тему, а не на пропаганду чистописания. А WTFcount чуть более чем 9000 сомнения не вызывает =)
Кстати с выходом последний версии значительно прибавил привлекательности… =)
Такс… Суть в том что обычные сокеты при большом пуле открытых соединений (актуально для не UDP протоколов) начинают тратить время на переключение контекстов потоков их обрабатывающих. Поняв это в Microsoft сделали IOCP, использование которой в дельфи я и продемонстрировал. IOCP это очередь сообщений на уровне ядра построенная специальным образом, так чтобы с помощью ограниченного кол-ва потоков обработать неограниченное кол-во запросов IO для любых конечных точек (сокеты файлы и т.д.).
Да я и не принимаю то =) Это часть стрим-сервера чат+видео+аудио. Сервер высоко нагруженный. Решил выложить, т.к. IOCP на дельфи оказалось в новьё. И никто ни слухом ни духом как его там прикручивать. По крайней мере из широкого круга программистов.
Честно сказать не расчитывал, что его будет много желающих прочесть… Просто реализаций таких сокетов на просторах очень мало, и я подумал что неплохо будет добавить.
CoInitialize вызвана при старте потоков чтобы обработчики событий которые вызовет класс могли использовать COM внутри себя… Интерфейсы в дельфи ничем на прямую с COM не связаны… По этому я их использовал для учёта того используется объект где-то в других потоках или нет.
waitformultiplyevent… где-то обнаружилась информация, что его использовать предпочтительнее в любом случае.
Я не использовал COM и автоматизацию… Интерфейсы тут — это хитрый ход для отслеживания объектов в очереди.
Это просто код с рабочего сервера откинутый в отдельный проект ради иллюстрации.
В посте есть ссылка на архив.
В посте есть ссылка на архив.
Я использую интерфейсы не для реализации COM объектов, а для того чтобы не создавать ручками класс где ведётся учёт ссылок, это опять таки нужно чтобы следить за памятью в событийно ориентированном программировании. С внутренней организацией интерфейсов в Delphi я знаком более чем.
А на мой взгляд, в таком виде легче менять логику всего что касается низкоуровнего программирования, winapi в частности. В приведённых листингах, по большому счёту, вообще альтернативы нет. Что насчёт флагов, так то и не флаги вовсе, а поля(сокращения от английской нотации, так в Delphi почти повсеместно), не зря готовый исходник прикреплен к началу. Посмотреть на рабочий итог в нём и можно.
А чем это плохо? Мне так было удобнее писать… А с точки зрения скорости, думаю, оптимизатор разберётся.

Information

Rating
Does not participate
Registered
Activity