>>Зачем эти сложности, если сразу можно вынести TCP/IP стек в юзерспейс?
> Позвольте, в чем глубокий смысл этой процедуры (кроме, разве что, легкости доступа
> к потрохам), чтобы выносить TCP/IP в юзерспейс? Процессору всё равно, какой
> код молотить - ядерный или юзерспейсный, и если в юзерспейсе реализовать
> все те же функции, что и в ядре, мы получим точно
> такую же производительность, что и в ядре.Потому что вопрос немного в другом: выбор не между выносить TCP/IP в юзерспейс или не выносить, выбор между засовывать ли весь код (включая сюда и http сервер) в ядро, или выносить весь код в юзерспейс. Задача стоит в том, чтобы разграничительная линия сисколлов проходила бы не между кодом http-сервера и TCP/IP стеком, а где-нибудь в другом месте, где эту линию можно будет реже пересекать.
> Легкость "подкручивания" - согласен. Но часто ли надо "подкручивать" TCP/IP?
TCP/IP не надо часто подкручивать, но вот реализацию TCP/IP заточенную под какие-то оптимизационные параметры и использующуюся для различных задач -- придётся. Возможно её придётся подкручивать под каждое конкретное применение. Оптимизация она такая.
> Вы говорите "оверинжиниринг", но полноценная юзерспейсная реализация TCP/IP будет точно
> таким же оверинжинирингом. От того, что вы вынесете код в юзерспейс,
> он не станет внезапно простым и лаконичным.
Оверинжиниринг -- это не просто количество кода, это скорее к тому, как много возможностей было заложено в код при проектировании, и как много из них оказалось востребовано. Дисбаланс между этими вещами либо приводит к костылестроению, вызванному тому, что библиотечный код неспособен решать задачи, которые он должен решать, либо этот дисбаланс приводит к оверинжинирингу, когда библиотечный код безумно сложен из-за того, что он рассчитан решать все задачи мира, в нём есть возможность подкрутить и настроить всё что угодно, в том числе и то, что никто никогда не подкручивает и не настраивает, но реально используется лишь часть этого. Скажем функция с двадцатью аргументами, из которых в 99 случаях из ста используются два первых, в остальные в 99 случаях передаются всякие значения типа 0, NULL, -1, nil и тп. Или безумная иерархия классов, из которых половина всегда создаётся дефолтным конструктором и никогда не меняется никем и ничем, несмотря на огромнейшие API позволяющие всё это настроить.
Вынос кода в юзерспейс позволяет более интересные способы взаимодействия между библиотечным кодом и клиентским. Не только сисколлы типа read/write, но скажем, итератор -- библиотека вполне может реализовать метод next, для перебора каких-либо сущностей, и этот метод может быть даже инлайн-функцией, если это надо. Библиотека может дать доступ к своей внутренней структуре и дать мне возможность либо читать её, либо даже менять -- может быть посредством непосредственной записи в поля, может быть посредством inline акцессоров, или может быть посредством сложных функций которые выполняют сложные действия. Это всё можно в юзерспейсе, это снимает кучу ограничений с разработчиков кода, это резко упрощает им задачу, и соответственно у них гораздо больше шансов получить _простой_ код, который с одной стороны не утонет в костылях, с другой стороны не будет на 90% неиспользуемым в реальности. Простой не в смысле количества строк кода, а в смысле того сколько потребуется времени, для того чтобы разобраться в этом коде и понять как этот код надо изменить, чтобы требуемым образом изменить поведение этого кода.
