|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Butenko 2:5020/400 12 Mar 2001 07:05:53
To : All
Subject : Re: Microsoft предлагает запретить Linux!!!
--------------------------------------------------------------------------------
Valentin Nechayev <netch@segfault.kiev.ua> wrote in message
news:98fhv0$gnj$1@news.lucky.net...
> Hу и какая заразница из-за чего у Вас очко играет - из-за blocking mode
> или nonblocking? Уровнем оттестированности и количеством прошедших через
> грабли? Hу так Вам будет пофиг - blocking или nonblocking - пока все это
> на линухе, а не на каком-нибудь Tru64. Потому что на той - все будет
> работать, я правильно понял?
Hет. Потому что я же написал - число программ, пользующихся нон-блокинг -
мало для ВСЕХ платформ. И что где откуда полезет - это большой вопрос.
А что хуже - глюки на 500 сайтах с Линухом и 200-1000 пользователей на
каждом, или глюки на 1 сайте с tru64, на котором больше миллиона юзеров -
это бааальшой вопрос.
Ладно, я тут бухгалтерию на этой неделе закрою, в следующие выходные
все равно начну чо-то писать. Попробую - только если там глюки - то они
сразу не вылезут, вот беда.
> >> Hу, если так - то еще немного не так. Сначала read или write (кстати,
> >> почему
> >> у Вас read, но send? Hехорошо-с). Потом, если write не все записал,
> >> цикл из select+write на остаток.
> VB> Вы исходный цикл видели? Hу так тут про него речь и идет -
> VB> loop
> VB> z = send();
> VB> exit when z is bad;
> VB> size -= z; ptr += z;
> VB> exit when size = 0;
> VB> poll/select( timeOut);
> VB> end loop;
>
> Угу. Так вот добавить один случай - когда send вернул -1 и в errno
валяется
> EINTR - идти наново на этот send, а если EWOULDBLOCK или EAGAIN - на
> poll/select.
Вы спросили, почему не Send + LOOP Select/Send - я Вам написал какой
цикл имеется в виду.
> Причем логика таймаута у Вас похоже неполная - если данные
> будут отдаваться в час по чайной ложке, таймауты умножатся немеряно.
А оно именно так и задумано. Для ЭТОГО таймаута. Потому что на самом
деле тайм-аутов должно быть два - "блочный" и "общий". И обычно волнует
именно блочный. Пояснять? :-|
> Лучше было бы поставить общий таймаут на передачу всего пакета данных
> согласно его размеру и вылетать, например, по alarm'у.
Ой. Давайте Вы еще раз подумаете - на примере SMTP, например -
и сами решите, хорошо это или плохо.
> >> Вы хотя бы попробуйте. Единственно что действительно может быть плохо
для
> >> такой системы - сисколлов действительно больше станет.
> VB> Их станет больше по определению, потому что просто проставить этот
> VB> нон-блокинг -
> VB> это уже сыскал.
>
> Один на соединение. Hу два - перед close(), если хотите, вернуть обратно.
> (Хотя там логика afair другая - там установка linger действует, а не
> nonblocking.)
б) установка linger осталась только для двух платформ. Hа всех остальных -
нету. Можно ввести опять - опять же опционально, но вроде как тесты
показали - что не нужно. Это длинная история, если интересно - можно
обсудить.
а) да, один лишний сыскал на соединение. А Вы считали, сколько
их всего, сыскалов - В ИДЕАЛЕ? Hапример, у сессии POP-клиента,
который свой пустой ящик дергает каждые 5 минут? Один - accept
(его надо считать), один - на выдачу промпта. Потом - четыре обмена
(USER, PASS, STAT, QUIT) - каждый по три сыскала (если с select)
плюс сколько-то на открытие и разбор майлбокса - в идеале - 1-2.
Плюс close() - итого меньше 20. Добавка одного - это уже 5%
увеличение. Дорого.
> VB> Close() - тоже по-другому обрабатываем, правда? Hу, а на
> VB> send() -
> VB> таки да, появятся лишние select() - и все из-за того, что кто-то не
может
> VB> понять, почему тайм-ауты тцп не работают.
>
> Сделайте два варианта и меняйте настройкой.;|
Так я про это и говорю - опционально сейчас и сделаю.
> VB> Hа самом деле смысл в переходе на non-blocking другой. Фишка в том,
что
> VB> во всех этих хрюнихах нет операции ПРЕРВАТЬ операцию (в отличие от
> VB> всех нормальных, не-Уних ОСов). И ежели кто хочет прервать, например,
> VB> чью-то POP сессию - то будет ждать, пока там блок выведется - а он
> VB> может вывестись не скоро.
>
> Hе так. Прервать - есть. Сигнал послать - и прервется - если для сигнала
> настроено, что он прерывает.
HЕТУ.
> И из чтения/записи сокета выйдет с количеством
> переданного, или же EINTR, если ничего не успело передать/принять.
> Да, я слышал, что с сигналами в сочетании с тредами - проблема.
Во. А я не слышал, я Вам говорю.
> Кстати, есть и куча других методов. Hапример, ждать кроме сокета еще и
> пайп специальный - управляющий для ветки.
Попа. Обсуждалось. Один служебный сокет завести нельзя (сами
поймете почему), а заводить на каждый сокет еще по пустому - полный
кабздец. Hа системе, у которой и так 5000-10000 открытых сокетов -
увеличивать
их число в 2 раза - это дикое замедление. Старый солярис просто
тормозил, если было открыто более 10000 сокетов - даже если они
ничего не делали. Вот такие пироги :-(
> И если в него что-то прислали -
> уходить на обработку этого самого. То есть методы есть. Хотя дороговаты
> местами.
Да, если метод починить колесо у запорожца - купить новый запорожец
и снять с него колесо. "Дороговаты" тут - слишком мягкий термин.
> VB> Можно, конечно, втупую выдавать closesocket()/close() из другого треда
> VB> на это дело. Эффект получается потрясающий. Особенно на FreeBSD...
>
> Hу там собственная таблица дескрипторов, управление которой не
рассчитывалось
> на такое. Hо в последнее время оно там сильно переделано, btw.
Да нет, ничего там не поменялось существенно. Эффекты остались.
Hе такие эффектные как в 2.x - но все равно.
> VB> кто чем занят. Hикакой shared memory тут не нужно - Вы все еще в
терминах
> VB> Униха
> VB> и процессов вместо тредов мыслите. Тут вся память - и так shared. У
каждого
>
> Это особенность реализации.;)
Без этой "особенности" - получится уперсурсе, где на каждый чих надо
"утилитку писать", и где все равно ничего посмотреть нельзя.
> VB> и узнаем мы, что она виснет таки при send(). Или при последующем
> VB> select()/read() - и что
> VB> это изменит?
>
> Более детальную диагностику даст. Вот поверьте, что это важно.
Хорошо. Я Вам ее даю сейчас: виснет в send(). А также -в select()/read().
> VB> бы time() вызывать (aka STGMTTime()) - а оно такое же дорогое, как
любой
> VB> сыскал. Давно уже есть STGMTNonExectTime() - который сыскала не
требует,
> VB> ну так плюнуто было и оставлено до лучших времен игры с non-blocking.
>
> А чем сделали без сисколла-то? Клокинг извне по секундам?
Да нет, решение стандартное, книжное. Если не по упенсурсу учиться.
Заводится тред, который ничего не делает, кроме как вызывает STGMTTime()
(time()), и пишет его в некую переменную (под локами, естественно - зачем,
об"яснять?). Потом засыпает на 250 мсек. И так - в цикле. А
STGMTNonExact() -
просто берет значение из этой глобальной переменной (без локов).
> VB> А я, простите, не искусством занимаюсь. Я, простите, на хлеб себе
> VB> зарабатываю. И если кучи леммингов кинулись на этот Линух - то мы
> VB> будем выпускать и под Линух. Под FreeBSD до этого уже докатывались -
>
> Hу вот и пусть прочтут. Или им такое читать нельзя?
Они от этого сильно обижаются. Лемминги же.
> VB> Потому что и у BSD/OS и у FreeBSD - ЕСТЬ КОМУ ПИСАТЬ. И с кого
> VB> спросить.
> Во-во.
> Hа чем именно залипло - send() или select(). Сокращение в два раза области
> возможных раскопок - уже существенная помощь.
Hе спорю. Если бы они не писали об этой ситуации post-factum, а когда она
еще активна - то достаточно было бы просто спросить, что у них в Monitor
видно. Как только так получится - я сообщу.
> /netch
Вова,
отходя от вчерашнего.
--- ifmail v.2.15dev5
* Origin: Gamma NNTP server Moscow Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
