Re: WSAxxx vs. unix-live IO (Re: fprintf && write)

From

Valentin Nechayev ()

To

Boris Rudakov ()

Date

2003-06-11T09:52:06Z

Area

CARBON.COPY

 * Forwarded from area 'RU.UNIX.PROG'
From: Valentin Nechayev <netch@segfault.kiev.ua>


>>> Boris Rudakov wrote:

 >>> 5. *Есть такая штука - юниксы* :):):):) куда код, основанный на
 >>> "фундаментальных" средствах API, портируется относительно просто, а
 >>> вот "оригинальное API", в данном случае WSAxxx - прибавляет лишнего
 >>> головняка.
 IS>> Для портирования в юникс единственный удобный интерфейс - это
 IS>> select/send/recv. Overlapped ReadFile/WriteFile и WSARecv/WSASend в
 IS>> плане портируемости ничем не отличаются.
BR> Немножко отличаются.
BR> В юниксах read умеет сокеты читать ? Я не пробовал пока, но удивлюсь если не
BR> умеет...

Умеет. С поправкой на то, что некоторые вещи через read() читать нельзя.
Например, если к датаграмме приложен control. Да, read() такое даже возьмёт,
кажется, но толку будет мало.

BR> Но если умеет, то еще раз повторюсь: проще всего повторить функцию на базе
BR> цикла ReadFile...GetOverlappedResult на идентичную по смыслу с циклом на
BR> read...select.

Опять ты пытаешься сравнивать асинхронное чтение с read...select.
Это разные случаи. read+select может быть эквивалентом или в пределах цикла
с множеством сокетов, или с учётом таймаута. При необходимости получить
в ветке пришедший поток, select() просто лишний. При объектах прямого доступа,
нужен aio_read().

 >>> НО: портировать в юникс функцию на цикле
 >>> ReadFile...GetOverlappedResult куда как проще, переделав ее в функцию
 >>> на цикле read...select, чем мудохаться с ни на что не похожими WSA.
 IS>> Как я уже сказал, WSARecv..GetOverlappedResult ничем не отличается
 IS>> от ReadFile...GetOverlappedResult.
BR> Я обдумаю эту идею...
BR> Все-равно мне в скорости предстоит портировать в юниксы здоровенный и очень
BR> сложный IO конвейер, все-равно его придется перекраивать чтобы учесть
BR> юниксоидные аспекты, так что можно будет еще и эту тонкость поизучать...

Этот конвейер работает с какими типами объектов? Есть ли файлы или плоские
диски? Сколько остального - сокетов, пайпов?

BR> ЗЫ: А за книгу я был бы в высшей степени признателен. Мой код сейчас делает
BR> Апач на ~20-30% (это очень мало), а IIS - на 200-250%. Этого мне мало. Хочу
BR> приблизиться к суперсерверам, типа того же Zeus (он Апача в ~5 раз делает на
BR> большой загрузке). Для достижения таких результатов мне знания тонкостей пока
BR> явно не хватает...

Я думаю, что книга сама по себе для такой оптимизации не годится.
А специфика какова? Апач потому медленный, что у него совершенно разные
типы отдачи и обработки слиты в одном флаконе и всё это ещё проходит через
конвейер обработки разными модулями. Упростив структуру, можно получить
ускорение на отсутствии сложной обработки.


-netch-
--- ifmail v.2.15dev5
 * Origin: Dark side of coredump (2:5020/400)