Конечно, серьезно. Не надо воспринимать все буквально, слово в слово. Главное: «сфера с очень большой добавленной стоимостью.» Сравните с созданием, например, автомобилей или другой машиностроительной продукции. Сначала вы потратитесь на землю, цеха, дорогущее оборудование, технологии, сырье. И только спустя какое-то время начнете потихоньку отбивать вложенное. С ПО картина иная. Это не плохо и не хорошо; это просто так — вложил не так много, отбил быстро (относительно). Суть именно в добавленной стоимости. Сравните, какая «обвязка» нужна абстрактному программисту для создания продукта (или математику, например; что ему нужно для работы?) и, например, рабочему сборочного конвейера автоконцерна.
Любой комбайнер вообще миллионер, надо только чтобы всегда было готовое к уборке поле и покупатели прямо с комбайна зерно забирали и деньги в кабину сразу передавали, сотни долларов в час делать можно, если не тысячи.
Нет, вы не поняли меня. Надо не только это, но и чтобы стоимость зерна была такова, что перекрывает и стоимость комбайна, и поля, и посевного материала. А этого не наблюдается, в отличие от.
Любая IT компания это система, команда разных специалистов
…
Программирование это важно, интересно, но работает только вся система, просто так код от фонаря никому кроме самого программиста особо не нужен.
Бесспорно, но все равно это — люди и их навыки. Да, может быть куплена какая-либо _технология_, но это не такое частое явление, если речь не идет про гигантов.
А зачем вообще связываться с select(), если у нас по потоку на коннект? Получили сокет из accept(), отдали его треду, пусть тред использует блокирующие вызовы
select позволяет отделить таймаут. Единственный оверхед, который я вижу это вызов WaitForMultipleObjects каждый раз, который наверняка делается внутри. Но это мизер по сравнению с самим вводом-выводом.
Также уменьшаются (немаленькие) накладные расходы на переключения контекста между задачами.
Думаю, в случае, если поток спит (win), то эти расходы малы. Поток проснется, когда будет, что делать. А в этом случае сам ввод-вывод, его обработка займут времени поболее переключения контекста, кмк.
Плюс в некоторых случаях, например, когда сервер является промежуточным звеном (нередкий сценарий), то обработка запроса потоком просто удобнее, в случае кругового опроса все равно придется создавать свой «контекст» в виде описания задачи и пр. И если потребуется ожидание ввода-вывода из другого источника, сохранение такого контекста много труднее, чем контекста потока.
Разумеется, минимальный размер стека регулируется, и оверхед можно существенно уменьшить, указав более подходящие значения.
Уже сталкивался с этим в Win32, там проблемы начинаются уже при меньшем количестве потоков (1000+-), но стек в 64к решает вопрос.
Если кому-то интересно, здесь есть хорошее описание ограничений Windows Mark Russinovich'ем, втч по кол-ву потоков в W32 и W64:
В Linux, раз уж речь идёт о epoll. В Linux процесс и поток — вещи по сути одинаковые.
приходится обходить почти весь список дескрипторов (точнее, вплоть до изменившегося дескриптора с максимальным номером)
То-есть, как я и предполагал, речь идет о ситуации, когда в один select загоняется массив со всеми (или просто большой частью) сокетов? В случае, если у нас каждое соединение обслуживается отдельным потоком, такой проблемы нет.
Есть также разница во внутренней реализации — select() добавляет процесс в N списков ожидания на каждом вызове. И после завершения select() процесс нужно отписать от N списков ожидания.
Процесс или поток? В какой ОС?
Сдается мне, здесь солидная разница в реализации между nix и Win.
+много.
IT сектор в целом, разработка ПО в частности — сфера с очень большой добавленной стоимостью. Вложил капитал в размере офиса, мебели и техники, получил солидную прибыль. Выше добавленная — выше зарплаты. Т.е. погроммист из ничего практически создает что-то дорогое.
Саму статью проглядел (в части 1 поток 1 соединение) до вашего ответа, но так и не понял, чем плох select. В данной статье, например, говорится о многопоточности в Apache и стратегии 1 поток — 1 соединение. Приводятся аргументы за и против (аргументы «против» вида «некоторые ОС не позволяют создать много потоков» не рассматриваем, т.к. 10к потоков создать можно в той же windows несмотря на кучу ограничений в этой области). В статье есть список Interesting select()-based servers.
Меня больше заинтересовали ваши слова о «сложности алгоритма опроса», этот момент остался непонятым, как и что есть «самый большой номер опрашиваемого файла».
Я могу, конечно, посмотреть на внутренности select в исходниках Linux или ReactOS, но, как я понял, вы уже разобрались в этом и можете что-то пояснить. Или я не понял вашу аргументацию против select'а.
Или вы имеете в виду ситуацию, когда 1м селектом опрашиваются 10к сокетов и на все один поток? Я-то о стратегии 1 соединение=1 thread = 1 socket = 1 select per socket.
select работает за O(самый большой номер опрашиваемого файла)
Насколько велик overhead при большом количестве соединений по сравнению со временем обработки самого запроса?
Что имеется в виду под «самый большой номер опрашиваемого файла»?
Где можно почитать подробнее про внутренности select? Обычно использовал select на поток для каждого порта, или thread pool. Ваше утверждение о select заинтересовало.
Ну, вот мне был интересен принцип отбора этих файлов.
" Еще есть функция отправки недетектов, если я не ошибаюсь, работает по принципу — кто-то детектит, вы нет, то получите файлик. "
Это самое простое — файл опознан как вредоносный кем-то, вами нет: получите, распишитесь. Я думал, есть и другие принципы выбора файлов для отправки.
На здоровье, я же со стороны рассуждаю, по слухам.
2) Куда конкретно отправляются? В базы? Вир-лабораторию? В /dev/null?
Во множестве мест видел упоминание, что VirusTotal отправляет какие-то образцы ав лабораториям. Пытаюсь разобраться — так это или нет, и по какому признаку отбираются кандидаты на отправку. Множество людей говорит, что есть такое; мне интересно — слух это или нет. К тому же, если бы такого не было, не было бы альтернативных, «теневых» сервисов с таким же функционалом.
Не совсем понятно, что Вы хотели узнать задавая вопрос:
Я имею в виду, что те образцы, которые были признаны АВ ПО вредоносными не по сигнатурам, а по шаблонному поведению — первые кандидаты на рассмотрение человеком, нет?
Возможно, остальные ленты пустые, возможно, запись полного набора производится на 2-3 ленты (записать на 1 ленту 3 млн пар фамилий нереально. В 80х по крайней мере). Ладно, замнем; просто задача допускает чуть разную трактовку. Так или иначе — есть ограниченная внешняя память. Хоть на 31 единицу, хоть на 15 — смысл задачи тот же.
Конечно, серьезно. Не надо воспринимать все буквально, слово в слово. Главное: «сфера с очень большой добавленной стоимостью.» Сравните с созданием, например, автомобилей или другой машиностроительной продукции. Сначала вы потратитесь на землю, цеха, дорогущее оборудование, технологии, сырье. И только спустя какое-то время начнете потихоньку отбивать вложенное. С ПО картина иная. Это не плохо и не хорошо; это просто так — вложил не так много, отбил быстро (относительно). Суть именно в добавленной стоимости. Сравните, какая «обвязка» нужна абстрактному программисту для создания продукта (или математику, например; что ему нужно для работы?) и, например, рабочему сборочного конвейера автоконцерна.
Нет, вы не поняли меня. Надо не только это, но и чтобы стоимость зерна была такова, что перекрывает и стоимость комбайна, и поля, и посевного материала. А этого не наблюдается, в отличие от.
Бесспорно, но все равно это — люди и их навыки. Да, может быть куплена какая-либо _технология_, но это не такое частое явление, если речь не идет про гигантов.
Коллега.
Предел по кол-ву поток в Win
select позволяет отделить таймаут. Единственный оверхед, который я вижу это вызов WaitForMultipleObjects каждый раз, который наверняка делается внутри. Но это мизер по сравнению с самим вводом-выводом.
Думаю, в случае, если поток спит (win), то эти расходы малы. Поток проснется, когда будет, что делать. А в этом случае сам ввод-вывод, его обработка займут времени поболее переключения контекста, кмк.
Плюс в некоторых случаях, например, когда сервер является промежуточным звеном (нередкий сценарий), то обработка запроса потоком просто удобнее, в случае кругового опроса все равно придется создавать свой «контекст» в виде описания задачи и пр. И если потребуется ожидание ввода-вывода из другого источника, сохранение такого контекста много труднее, чем контекста потока.
Уже сталкивался с этим в Win32, там проблемы начинаются уже при меньшем количестве потоков (1000+-), но стек в 64к решает вопрос.
Если кому-то интересно, здесь есть хорошее описание ограничений Windows Mark Russinovich'ем, втч по кол-ву потоков в W32 и W64:
Ясно; у меня основной опыт с Win32.
Вы пропустили конструктора.
Часть делает инженер, часть конструктор (чертежи, доументация, конкретика).
То-есть, как я и предполагал, речь идет о ситуации, когда в один select загоняется массив со всеми (или просто большой частью) сокетов? В случае, если у нас каждое соединение обслуживается отдельным потоком, такой проблемы нет.
Процесс или поток? В какой ОС?
Сдается мне, здесь солидная разница в реализации между nix и Win.
IT сектор в целом, разработка ПО в частности — сфера с очень большой добавленной стоимостью. Вложил капитал в размере офиса, мебели и техники, получил солидную прибыль. Выше добавленная — выше зарплаты. Т.е. погроммист из ничего практически создает что-то дорогое.
Меня больше заинтересовали ваши слова о «сложности алгоритма опроса», этот момент остался непонятым, как и что есть «самый большой номер опрашиваемого файла».
Я могу, конечно, посмотреть на внутренности select в исходниках Linux или ReactOS, но, как я понял, вы уже разобрались в этом и можете что-то пояснить. Или я не понял вашу аргументацию против select'а.
Или вы имеете в виду ситуацию, когда 1м селектом опрашиваются 10к сокетов и на все один поток? Я-то о стратегии 1 соединение=1 thread = 1 socket = 1 select per socket.
Насколько велик overhead при большом количестве соединений по сравнению со временем обработки самого запроса?
Что имеется в виду под «самый большой номер опрашиваемого файла»?
Где можно почитать подробнее про внутренности select? Обычно использовал select на поток для каждого порта, или thread pool. Ваше утверждение о select заинтересовало.
" Еще есть функция отправки недетектов, если я не ошибаюсь, работает по принципу — кто-то детектит, вы нет, то получите файлик. "
Это самое простое — файл опознан как вредоносный кем-то, вами нет: получите, распишитесь. Я думал, есть и другие принципы выбора файлов для отправки.
На здоровье, я же со стороны рассуждаю, по слухам.
Во множестве мест видел упоминание, что VirusTotal отправляет какие-то образцы ав лабораториям. Пытаюсь разобраться — так это или нет, и по какому признаку отбираются кандидаты на отправку. Множество людей говорит, что есть такое; мне интересно — слух это или нет. К тому же, если бы такого не было, не было бы альтернативных, «теневых» сервисов с таким же функционалом.
Я имею в виду, что те образцы, которые были признаны АВ ПО вредоносными не по сигнатурам, а по шаблонному поведению — первые кандидаты на рассмотрение человеком, нет?