Vlákno názorů ke článku Optimalizace async. parseru JSON v C++20 od jbv - Já se přiznám, že pořád nechápu, proč trváš...

Já se přiznám, že pořád nechápu, proč trváš na asynchronním parseru? Nebylo by lepší použít stream parser s tím, že asynchronní čtení se vyřeší mimo parser? Ještě bych pochopil něco takového dělat pro studijní účely, ale proč to potom proboha optimalizovat?

Já kdybych psal json parser s použitím minima paměti, tak bych spíš použil libovolný stream parser a čtení dat bych dělal přes IO_uring a mmapované buffery do kernelu. IMHO by to bylo rychlejší i paměťově úspornější než cos napsal (nečetlo by to po bytech a zároveň by se nekopírovala paměť z kernelu do user spacu), jen by to běželo jenom na linuxu.

Nebo mi uniká nějaký důvod proč psát něco takového?

mohl bych stream parser vidět?

Jen abysme si ujasnili o co jde. Jde o to, že nechceš blokovat vlákno, když čekáš na IO. Prostě se ti spojeni v půlce parsování zasekne, nechceš blokovat vlákno, pokud máš jen omezený množství vláken a mnoho requestů.

Třeba útok slowloris se pak dělá velice snadno

Samozřejmě, snadné řešení je stáhnout celý obsah do paměti asynchronně jako blok bajtů a pak to teprve parsovat. Pokud víš, kolik toho máš stáhnout (na bajt)

Pokud myslíš parser, který ti volá callbacky s každým přijatým blokem dat, tak to se přece nevylučuje. První čtení si nastaví strea, a pak kdykoliv mi přijde callback s daty, tak buffer předám awaiteru a zavolám resume, provede se parsování toho bloku a na konci ho hodím zpět do suspend a vrátím se s callbacku a čekám na další callback. Jakmile se načte všechno, korutina ohlásí konec. Jako tohle řešení nepředepisuje, co se má použít jako zdroj dat. Může se použít i zero copy buffer, protože jediné co se vyžaduje je std::string_view. Kopírování dat nikde nedochází, pokud tedy nemyslíš kopírování znaků v řetězcích do datových struktur k tomu určených.