В него копируют внутри сисколла

мы читаем из него, а не пишем. ядро пишет

я вот не уверен, но спорить не буду, не знаю потому что

ща погуглю

Мы читаем из буфера конечно не сисколлом. Заполняется он сисколлом во время вызва recv...

Мы читаем из буфера конечно не сисколлом. Заполняется он сисколлом во время вызва recv...

это если вызов блокирующий, а если данные уже лежат в буфере и мы тянем только их, то ничего в буфер не пишется. А именно такой случай мы тут и обсуждаем.

epoll или select нам сообщают, что данные есть, узнаем длину и читаем. Либо сразу все, либо частями. Экономия не на сисколлах, а на просто коллах.

это если вызов блокирующий, а если данные уже лежат в буфере и мы тянем только их, то ничего в буфер не пишется. А именно такой случай мы тут и обсуждаем.

А как они в буфер попали?

например во время вызова epoll_wait

даже если будем тупо потенциально блокирующий recv делать все равно не каждый раз будет сисколл делать, а только если данных в буфере не хватает для чтения указанного количества байт

Нет, еполл только скажет что есть что читать

Что в буфере ядра сокеты есть данные

Нет, еполл только скажет что есть что читать

по-твоему система пишет данные не сразу в буфер сокета, а сначала куда-то еще?

зачем так делать?

накой тогда вообще нужен буфер?

Ну блин. Данные из драйвера езернета попадают в буфера ядра, там обрабатывется уровнем тсп и раскладывается в ядре по буферам сокет. Из этих буферов в ядре читаем в юзерспейс во время recv

Мы об этом говооим?

ага

и данные в буфер сокета пишутся до того как делается реальное чтение

Assuming the packet is in sequence, the data payload is then copied into the socket’s receive buffer. At this point the kernel will wake up any processes doing a blocking read(2), or that are using an I/O multiplexing system call like select(2) or epoll_wait(2)to wait on the socket. When the userspace process actually calls read(2) on the file descriptor it causes the kernel to remove the data from its receive buffer, and to copy that data into a buffer supplied to the read(2) system call.

буфер ядра -> буфер сокета -> юзерспейс так выходит?

нет

буфер ядра и буфер сокета это одно и то же?

Да

NIC -> буфер сокета -> юзерспейс

Они оба в ядре

А в NIC там что? Тоже какой-то буфер?

И может ли из него читать не ядро?

А в NIC там что? Тоже какой-то буфер?

сетевая карта, у нее внутри наверное есть свой буфео

И может ли из него читать не ядро?

насколько я понимаю нет

полюбому будет копирование в юзерспейс

А если написать ядерный модуль, то все равно никак в него нельзя залезть из юзерспейса?

Хотя глупый вопрос, можно конечно )

А если написать ядерный модуль, то все равно никак в него нельзя залезть из юзерспейса?

может и можно, я не эксперт в таких низкоуровневых вещах

юзерспейс же как-то читатет все остальное

Ну короче, главное что у нас TCPConnection работает в юзерспейсе и само имеет буфер. А я еще копирую его в свой буфер приложения.

Ну короче, главное что у нас TCPConnection работает в юзерспейсе и само имеет буфер. А я еще копирую его в свой буфер приложения.

точно?

а что тут может быть не точного?

это же просто интерфейс, а наличие буфера это детали реализации

я не уверен что в стандартных драйверах есть отдельный буфер, накой он нужен?

ну с этой точки зрения да

но вроде как есть метод peek() который дает указатель на внутренний буфер TCPConnection

https://github.com/vibe-d/vibe-core/blob/master/source/vibe/core/net.d#L589 да вот он) это часть интерфейса и прямо на внутренний буфер

хорошо, теперь уверен :)

но если есть peek, значит копировать в еще один буфер не обязательно

кстати в линупсе есть http://man7.org/linux/man-pages/man2/splice.2.html

? буду рефакторить

? буду рефакторить

там по-моему вообще можнт напрямую стримить из сокета в сокет

Да я видел, но как-то меня не устроило, не помню уже почему

Вроде потому что там что-то крешилось

http://vibed.org/api/vibe.core.stream/pipe

узнаем длину доступных данных и стримим

крешилось или эксепшн кидало?

Щас не помню, перепроверю

Ассерт

Я запускал 2 таска - передача данных между сокетами в две стороны

Один таск закрывал сокет при окончании передачи а другой слетал с ассертом

не надо, он внутри все равно через доп буферы гоняет

я посмотрел исходники, никакого peek там нет

видимо потому что на generic стримы рассчитан

а peek это походу чисто сокетовский метод

Ассерт

это бага по любому, должен просто эксепшн кидать

https://dlang.org/blog/2018/02/03/the-dbugfix-campaign/

Надо разбираться с dmd и помогать фиксить)

Надо разбираться с dmd и помогать фиксить)

Давно такая мысль в голове крутится, но порог высоковат. А материала для входа очень мало

вот, вот. Я даже точку входа найти не смог

Добрый день. У меня есть вопрос: а dlangui запускается с dsfml? Я видел пример на гитхабе в dlangui-example, но заставить его работать мне не удалось.

я, увы, не разбираюсь в dlangui

ERROR: S client not available

Много вылезает проблем еще на этапе компиляции, типа: -при подключении dlangui, статические либы dsfml линкер не обнаруживает нигде, кроме как рядом с файлом dub.json, далее нигде не указано, что надо еще подключать gdi32.lib Далее при запуске обнаруживается, что не подгружается opengl через derelict и оно падает с Access Violation. А после этого оно просто не рисует ничего, то есть sfml свой смайлик рисует, а вот dlangui - ничего. Если что, то компилирую последним dmd в х86, все остальное - как в примере. Надеюсь кто-то сможет помочь

Много вылезает проблем еще на этапе компиляции, типа: -при подключении dlangui, статические либы dsfml линкер не обнаруживает нигде, кроме как рядом с файлом dub.json, далее нигде не указано, что надо еще подключать gdi32.lib Далее при запуске обнаруживается, что не подгружается opengl через derelict и оно падает с Access Violation. А после этого оно просто не рисует ничего, то есть sfml свой смайлик рисует, а вот dlangui - ничего. Если что, то компилирую последним dmd в х86, все остальное - как в примере. Надеюсь кто-то сможет помочь

Напишите Вадиму Лопатину в гитхабе в разделе issues.

а тут есть кто разбирается в assembly? RSI регистр - всегда указатель?

Много вылезает проблем еще на этапе компиляции, типа: -при подключении dlangui, статические либы dsfml линкер не обнаруживает нигде, кроме как рядом с файлом dub.json, далее нигде не указано, что надо еще подключать gdi32.lib Далее при запуске обнаруживается, что не подгружается opengl через derelict и оно падает с Access Violation. А после этого оно просто не рисует ничего, то есть sfml свой смайлик рисует, а вот dlangui - ничего. Если что, то компилирую последним dmd в х86, все остальное - как в примере. Надеюсь кто-то сможет помочь

То самое чувство, когда проще плюнуть и взять winapi

То самое чувство, когда проще плюнуть и взять winapi

Это проблема возникает, если использовать в связке с dsfml

Так все нормально работает

Что за хрень такая?

Что за хрень такая?

dsfml?

Да

Это либа для создания 2д приложений

ну типа там игры например

Автор dlangui на хабре в комментариях показывал скрин, как связал это вместе

У меня уже на компиляции проблемы

Он на винде это делал?

Он на винде это делал?

Да, ибо либы в примере для винды

https://sourceforge.net/projects/wxd/

А это дрочибельно?

Даже не знаю, мне dlangui нужен для редактора внутри игры

Даже не знаю, мне dlangui нужен для редактора внутри игры

а не лучше использовать nuclear?

https://github.com/vurtun/nuklear

Вопрос в том, насколько сложно его подружить с dsfml

https://github.com/vurtun/nuklear

Ооо какая красота

Надо потыкать

Вот да

Биндинг для D сделать не хитро будет

уже есть

а вот с sfml нашел как соединяется

уже есть

Дай ссылку

https://github.com/mogud/nukleard

Проблема номер 2: как его сбилдить для dmd?

ну статическую либу

OMF же вроде?