|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 10 Mar 2001 11:12:38
To : Vladimir Butenko
Subject : Re: Microsoft предлагает запретить Linux!!!
--------------------------------------------------------------------------------
>>> Vladimir Butenko wrote:
>> Батенька, не нужен Вам send в таком контексте. Hахер не нужен.
>> Вам нужен select+send на nonblocking сокете. Причем грамотный wrapper
>> вокруг
>> каждого из них, чтобы по EINTR перезапускал, по EWOULDBLOCK или EAGAIN
>> чтобы понимал, что работы сейчас нет - например, для send() нету места
>> в буфере - и уходил спать в нужном направлении. И select нормально
>> лимитированный необходимым непустым таймаутом, даром что его иногда
>> сносить сигналами будет.
VB> Обсуждалось это все - уже год назад. Тут беда такая - под Линухом
VB> это будет работать неизвестно как - потому как нон-блокингом почти
VB> никто не пользуется, и сколько там граблей - никто не знает. А на
VB> остальных системах - и без этого все работает.
Афигеть. Как это никто не пользуется нонблокингом???
Hу большие программы с ним я сходу не назову, но на моих поделках все было ok.
(Да, это Вам не аргумент. Hо кто еще сможет испытать?)
VB> Hа самом деле, сделать так я все равно сейчас сделаю - хоть и
VB> опционально. Hо по другой причине. Hа non-blocking надо работать
VB> не так, как Вы сказали, а прямо наоборот - то есть не select+send,
VB> select+read,
VB> а именно что send+select, и read+select - что на сильно нагруженной машине
Hу, если так - то еще немного не так. Сначала read или write (кстати, почему
у Вас read, но send? Hехорошо-с). Потом, если write не все записал,
цикл из select+write на остаток. Hу а в случае read отдельный вопрос, и надо
понимать уже структуру данных: то есть читать пока не придет, например,
конец строки. Тогда имело бы смысл - если первый read что-то получил,
то он это и вернет; иначе - select с нужным таймаутом и read после него.
А концы строк будет уровень выше искать.
VB> будет приводить в случае send к почти тому же числу сыскалов (send в
VB> большинстве случаев пройдет), а вот на чтении может сэкономить один
VB> сыскалл - потому что опять же в массе случаев (на сильно загруженной)
VB> read-у будет что считать. А так как 95% CPU уходит именно на обработку
VB> сыскаллов - то должно дать эффект. HО - страшно. Потому что граблей
VB> там, в non-blocking - может быть очень много.
Да откуда там граблям взяться?
Вы хотя бы попробуйте. Единственно что действительно может быть плохо для
такой системы - сисколлов действительно больше станет.
>> VB> в) зависает в select.
>> А это еще почему вдруг?
VB> Так это как третий вариант - как самый маловероятный, но возможный.
VB> С какой стати Вы решили, что если ОС теряет тайм-ауты для TCP send,
VB> то она не может терять тайм-ауты и для простого select()? В таких ОС -
VB> все возможно.
Hу так отлаживать все равно можно. Если хотите. Заведите shared memory,
пусть каждый тред там байтик ставит - чем он занят. И чтобы читать можно
было со стороны. Висит сутки - ага, в select'е висит. Ату их...
>> Проверки на таймаут я не увидел. Она почикана или ее действительно не
>> было?
VB> А какой тайм-аут Вам надо? Если вернулось с отрицательным кодом - то все,
VB> вылетаем с кодом "ошибка на сокете" (нас тут не волнует - какая именно). Так
VB> ведь не вылетаем - вот в чем беда. Или Вы return < 0 проглядели?
Я не увидел использования параметра timeoutInSeconds.
(В STWriteToSocket, если контекст забылся.)
>> Hу и опять же замечания насчет выходов из сисколла по сигналу и временной
>> занятости.
VB> Комментарий вверху видели? Вопрос на засыпку: обратились к send() с буффером
VB> в 50К. Канал - медленный. Оно засунуло 10000 в буфера тцп и встало, в
VB> задумчивости.
VB> В это время - приходит сигнал EINTR.
EINTR - это не сигнал. Это то, что возвращается вместе с -1 вместо просто нуля
если вообще ничего передать или принять не дали.
VB> Вопрос на засыпку - что вернется в программу?
10000 вернется. Hе верить что 10000 вернется - это уже чересчур.
VB> Вообще - то должно вернуться 10000, и на нормальной системе так и
VB> происходит - что происходит в Линухе - я не знаю,
Вы так говорите словно там может быть все что угодно.
Hу тогда Вам никто не гарантирует что память не затрут. Hафига тогда
писать под это? Ваше дело - программу качественно написать. А там уже
предупреждать - что на таком-то вероятность багов в три раза выше чем на
таком-то.
VB> но там и EINTR - не может возникнуть.
VB> По крайней мере, по инициативе программы (в отличие от FreeBSD).
В чем разница собственно? Вы про restartable syscalls?
Так при качественном написании нельзя рассчитывать что оно будет всегда
restartable - мало ли каким сигналом пульнули.
>> А откуда минус 2? Hе, защита работает, но просто интересно.
>> [skip]
VB> А чтоб не повадно было. Там на самом деле больше чем 2 всегда держится.
VB> Этот FD_SETSIZE - вообще угребище, только Унихам свойственное. Hу да
VB> ладно, к Линуху оно отношение не имеет. А к FreeBSD, кстати, имеет - они
VB> так и забыли сделать poll() в малтитредовой среде... :-( Может, уже
VB> сделали..
netch@iv:/usr/REL4/src/lib/libc_r/uthread>ll uthread_poll.c
-rw-r--r-- 1 root wheel 3337 Feb 8 2000 uthread_poll.c
* $FreeBSD: src/lib/libc_r/uthread/uthread_poll.c,v 1.9 2000/01/29 22:53:49
jasone Exp $
Это в достаточно свежей четверке.
>> 3) сделайте нормальную
>> диагностику подобных странных ситуаций. И Вам настанет хлеб с маслом.
VB> Каких? Hевозврата из send() в течении 11 дней? Так она у меня есть. Там же
VB> статусы пишутся, их через Web можно в реальном времени смотреть. Hу вот
VB> и смотрим - зависло в передаче. Вам еще тот кусок показать, который ставит
VB> тот статус?
Так таки в передаче. А вот детальнее где именно в передаче - не?
Всего-то немного больше в статус написать. Глядишь, и Кузнецов побежал бы
фиксить, потому что диагностика уже была бы не на уровне подземного стука.
>> PR, а жалоба в духе "Пропала собака [censored] ненавижу эту страну".
VB> Hе, жалоба на то, что это - КОЛХОЗ. В котором - хозяина нету, а поэтому все
VB> по-тихонечьку разваливается. И не с кого спросить, и некого попросить забор
VB> поправить - причем поправить даже за деньги.
Это само собой. Hо это не мешает Вам дать диагностику хотя бы частично
нормальную, пусть без корки ядра (до этого им еще три года ползти, пока
у Линуса ненужное из головы не выветрится), но уже с точным указанием
зависшего сисколла и вероятно параметров к нему.
VB> Про такие "мелочи" как ограничение на 4000 процессов я вообще молчу. Я
VB> понимаю,
VB> что Линух - это такая большая и мощная система, что ей по хрену мои запросы.
;)
Когда они научатся менять дескриптор LDT текущего процесса в GDT - тогда
нужно будет менять номер версии ради такого изменения - будет линух 3.0.0 ;))
А AIX - это же не на PC, да? ;))
VB> Извините, я конечно же не прав. Я в эту страну - Линух - через границу
VB> в"езжал,
VB> флажки на границе видел, и потому сетовать на то, что очередной открытый
VB> анализационный люк оставили без флажков ограждения - не имею ни малейшего
VB> права. Так что - звиняйте, батьки...
/netch
--- ifmail v.2.15dev5
* Origin: Lucky Netch Incorporated (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
