Relational pipes v0.15

Byla vydána nová vývojová verze datového formátu a souvisejících nástrojů Relational pipes. Hlavní novinkou verze v0.15 jsou tzv. streamlety, pomocí kterých lze rozšiřovat funkcionalitu, a paralelní zpracování (využívá POSIX MQ), díky kterému lze např. počítat SHA-256 hashe více souborů současně nebo paralelně získávat metadata ze souborů (Exif, JPEG, PNG, PDF atd.) nebo paralelně vyhodnocovat XPath výrazy. Dále byla vylepšena práce s XML (podpora XInclude a různých režimů hodnot u XPath výrazů) a pro kódování čísel se nově používá SLEB128.

4.2.2020 04:00 | xkucf03 | Nová verze

Komentáře

[Josef Kufner]

Předpokládám, že to paralelní zpracování stále předává data mezi filtry sériově jednou rourou, nebo je tam nějaká obezlička i pro paralelizované předávání?

Btw, Grammarly je docela fajn věc.

[xkucf03]

Předpokládám, že to paralelní zpracování stále předává data mezi filtry sériově jednou rourou

Ano. Tohle je tak nějak podstata těch Relational pipes, že jde o proud dat, který se dá předávat rourou mezi procesy. :-)

To paralelní zpracování se odehrává uvnitř jednoho modulu. V současnosti je implementované v relpipe-in-filesystem a bude v relpipe-tr-streamlet. Ve zkratce to funguje tak, že rodičovský proces forkne podprocesy, a pak posílá úlohy do POSIX MQ fronty, ze které si je podprocesy berou. Podprocesy pak zapisují do společného STDOUT, kde se jen synchronizují přes zámek (POSIXový semafor). Podrobněji je to rozepsané v oznámení nové verze.

nebo je tam nějaká obezlička i pro paralelizované předávání?

Není. Teoreticky by se dalo vymyslet něco na způsob: do roury by každý pod-proces zapsal jen odkaz na sdílenou paměť nebo frontu či soket a data by už tekla tamtudy. Ale nevidím v tom moc smysl – jednak to úzké hrdlo bude někde jinde (počítání hashů nebo zjišťování metadat atd. ti zabere více času než předání výsledku nebo načtení názvu souboru ze vstupu) a jednak by to narušovalo transparentnost (dneska tu rouru můžeš postavit přes několik počítačů a přeposílat to po síti přes SSH nebo TCP či SCTP).

Něco podobného se tu diskutovalo minule, když se řešilo, zda by nešlo mít v unixu ty roury mezi procesy obousměrné a umožnit procesům si nějak domlouvat formát dat. Teoreticky by to šlo, ale vypadá to, že by to bylo víc práce než užitku. Podobně jsou na tom ty fantazie o objektovém OS – teoreticky by to bylo skvělé, ale otázka je, kdy/jestli si na to někdo udělá čas a reálně to implementuje. Do té doby mi přijde lepší stavět na tom, co máme a jen to mírně vylepšovat, posouvat dál.

Možná až/jestli bude ta alternativní implementace postavená (asi) na GraalVM, kde všechno poběží v jednom procesu a místo serializace a deserializace proudů bajtů se budou jen volat metody jednoho programu… tak tam by šlo přidat i tuhle optimalizaci (záznamy by mohly i mezi jednotlivými fázemi putovat paralelně).

[Josef Kufner]

Ok. To ní smysluplně.

Možná až/jestli bude ta alternativní implementace [...]

Tuto evoluci si můžeš ušetřit a skočit rovnou na TensorFlow

[luky]

Něco podobného se tu diskutovalo minule, když se řešilo, zda by nešlo mít v unixu ty roury mezi procesy obousměrné a umožnit procesům si nějak domlouvat formát dat.

Treba neco jako socketpair(AF_UNIX, SOCK_STREAM, 0, fd);?

[xkucf03]

Ano. Teoreticky by stačilo, kdyby shell¹ místo pipe() zavolal socketpair() a nastavil ho procesům na příslušné STDIO FD. Asi by tam bylo potřeba doladit nějaké detaily (kolem zavírání?) ale v zásadě by to mohlo fungovat jako lepší náhrada jednosměrné roury (pro programy, které s touto funkcionalitou nepočítají).

Program by pak mohl i zapisovat do STDIO resp FD 0 a tím něco signalizovat procesu, který mu má poskytovat data, a mohl by i číst ze STDOUT resp. FD 1 a dívat se, co mu signalizuje konzument jeho dat. Nevím ale, jak by měl vypadat ten protokol – která strana by měla začít s komunikací a zkoušet, jestli druhá strana podporuje obousměrné roury. Druhá strana totiž může být klasický program podporující jen jednosměrné roury a pak bychom čekali na zprávu od konzumenta našich dat, která by nikdy nepřišla. To by sice „vyřešil“ nějaký ten timeout, ale ten by přidal konstantní zpomalení ke všemu, co podporuje jen jednosměrné roury (minimálně v počátku drtivá většina programů), takže tudy cesta nevede.

Asi by to tam šlo nějak dohackovat ve stylu: pokud program podporuje obousměrné roury, tak by měl před prvním voláním read()/write() zavolat nějakou jinou funkci, která by druhému procesu poslala na pozadí signál, že jeho protějšek podporuje obousměrné roury. Ten druhý proces by pak věděl, že před posíláním výstupu si má např. přečíst z FD 1, jaké formáty jeho protějšek podporuje. Tím by možná šel zajistit plynulý přechod systému z jednosměrných rour na obousměrné…

P.S. našel jsem tu předchozí diskusi: obousměrné signalizace na rouře.

_{[1] nebo libovolný jiný program, který spouští podprocesy a propojuje je rourami}

[upozorneni]

UPOZORNÉNÍ --- Autor tohoto softwaru je ruský kolaborant, podobruje šíření ruských desinformací ve válce o Ukrajinu.