Size: a a a

2021 June 30

И

Игорь in dlang.ru
Или этим gc занимается?
источник

EP

Egor Pugin in dlang.ru
конкретно тут я предлагаю http запрос целиком получить и хранить
источник

Е

Евгений in dlang.ru
То бишь копировать куски запроса пока он целиком не придет.
источник

И

Игорь in dlang.ru
Целиком? Ты не знаешь его размер заранее
источник

Е

Евгений in dlang.ru
Зачем это делать, если можно сразу приступить к парсингу?
источник

EP

Egor Pugin in dlang.ru
я и говорю, можно парсить уже там 100 байт начать
источник

Е

Евгений in dlang.ru
Так можно начать БЕЗ копирования.
источник

Е

Евгений in dlang.ru
А ты предлагаешь начать с копированием.
источник

EP

Egor Pugin in dlang.ru
ну и если это большой запрос, то хедеры обычно занимают меньшую часть, а пейлоад мы никак не можем выкидывать раньше времени в большинстве случаев
источник

И

Игорь in dlang.ru
Можем и пейлоад если он зипованный а мы его декомпрессим
источник

И

Игорь in dlang.ru
Неважно большой или нет, ты не знаешь жтого заранее
источник

Е

Евгений in dlang.ru
Всякое случается. Особенно если у тебя запросы идут один за одним в одном соединении. Там может и ползаголовка прийти.
источник

EP

Egor Pugin in dlang.ru
мы умеем находить границу сообщений
источник

Е

Евгений in dlang.ru
Разница в том, что в обсуждаемом случае сокет отдает буфер тебе, а в твоем, что буфер принадлежит сокету и ты вынужден из него копировать в свой буфер.
источник

Е

Евгений in dlang.ru
Можно кстати атомики не использовать и запретить обрабатывать веревку из разных потоков.
источник

EP

Egor Pugin in dlang.ru
хм, вообще буфер всегда мой для сокета
источник

EP

Egor Pugin in dlang.ru
я немного тут не понял
источник

Е

Евгений in dlang.ru
Ага, но обычно этот буфер один и тот же.
источник

EP

Egor Pugin in dlang.ru
да, из него поэтому данные пришедшие копируем и складываем
источник

Е

Евгений in dlang.ru
Если же подсовывать разные буферы, а уже прочитанные забирать себе, то получится nbuff :)
источник