Зависит от ВУЗа. У нас было такое требование — дипломный проект надо оформлять по ЕСПД, соответственно, есть минимальный комплект документации. Т.е. есть исходники, описание алгоритмов, рук-во оператора и пр. Это идет в приложение, не в сам диплом (я приложение на CDшке подклеивал).
Если у вас дипломная работа, то можно и не включать.
Но если дипломный проект (специалитет), то проект выполняется полностью. с документацией.
Выбил 11 из 15, т.е. Ready for real-life C.
Вариант 6 "… by tricking the system" и первый запуск с отключенными скриптами в браузере, при которых ответ сразу высвечивается справа, навел на мысли…
У меня 158 страниц было без каких бы то ни было исходников или других приложений (это еще сотни, на компакт пошло).
Не представляю, как может быть диплом с экономикой в 50 стр.
Да и не всегда радуга на экране хороша. Порой идеал — два-три цвета. Просматривая исходники в FARе, понимаешь, почему и зачем придумали форматирование, определенный шаблон комментариев и расстановки скобок — эти участки различаешь очень быстро и без цвета. Потом рассматривая какой-нибудь нечитаемый код в современной ИДЕ с радужной подсветкой, думаешь, что автор никогда не использовал бы вот такие дурацкие идентификаторы и такое идиотское форматирование, если бы не было цвета.
Хотите научить ребенка разговаривать — не сюсюкайте с ним, говорите как со взрослым.
Здесь тот же принцип.
Не надо спускаться на чей-то уровень; этого кого-то надо подтягивать на свой. Если все объяснять в понятных терминах, терминах, которые он знает, то он _никогда_ не узнает новых, верно? Ибо зачем узнавать новые, если все объясняется в уже известных?
Конечно, серьезно. Не надо воспринимать все буквально, слово в слово. Главное: «сфера с очень большой добавленной стоимостью.» Сравните с созданием, например, автомобилей или другой машиностроительной продукции. Сначала вы потратитесь на землю, цеха, дорогущее оборудование, технологии, сырье. И только спустя какое-то время начнете потихоньку отбивать вложенное. С ПО картина иная. Это не плохо и не хорошо; это просто так — вложил не так много, отбил быстро (относительно). Суть именно в добавленной стоимости. Сравните, какая «обвязка» нужна абстрактному программисту для создания продукта (или математику, например; что ему нужно для работы?) и, например, рабочему сборочного конвейера автоконцерна.
Любой комбайнер вообще миллионер, надо только чтобы всегда было готовое к уборке поле и покупатели прямо с комбайна зерно забирали и деньги в кабину сразу передавали, сотни долларов в час делать можно, если не тысячи.
Нет, вы не поняли меня. Надо не только это, но и чтобы стоимость зерна была такова, что перекрывает и стоимость комбайна, и поля, и посевного материала. А этого не наблюдается, в отличие от.
Любая 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 заинтересовало.
Если у вас дипломная работа, то можно и не включать.
Но если дипломный проект (специалитет), то проект выполняется полностью. с документацией.
Вариант 6 "… by tricking the system" и первый запуск с отключенными скриптами в браузере, при которых ответ сразу высвечивается справа, навел на мысли…
Не представляю, как может быть диплом с экономикой в 50 стр.
Здесь тот же принцип.
Не надо спускаться на чей-то уровень; этого кого-то надо подтягивать на свой. Если все объяснять в понятных терминах, терминах, которые он знает, то он _никогда_ не узнает новых, верно? Ибо зачем узнавать новые, если все объясняется в уже известных?
Конечно, серьезно. Не надо воспринимать все буквально, слово в слово. Главное: «сфера с очень большой добавленной стоимостью.» Сравните с созданием, например, автомобилей или другой машиностроительной продукции. Сначала вы потратитесь на землю, цеха, дорогущее оборудование, технологии, сырье. И только спустя какое-то время начнете потихоньку отбивать вложенное. С ПО картина иная. Это не плохо и не хорошо; это просто так — вложил не так много, отбил быстро (относительно). Суть именно в добавленной стоимости. Сравните, какая «обвязка» нужна абстрактному программисту для создания продукта (или математику, например; что ему нужно для работы?) и, например, рабочему сборочного конвейера автоконцерна.
Нет, вы не поняли меня. Надо не только это, но и чтобы стоимость зерна была такова, что перекрывает и стоимость комбайна, и поля, и посевного материала. А этого не наблюдается, в отличие от.
Бесспорно, но все равно это — люди и их навыки. Да, может быть куплена какая-либо _технология_, но это не такое частое явление, если речь не идет про гигантов.
Коллега.
Предел по кол-ву поток в 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 заинтересовало.