pipe v c

Jan Kasprzak kas na fi.muni.cz
Úterý Prosinec 5 09:28:29 CET 2017


Milan Kratochvíl wrote:
: Zdravim vsechny,
: 
: chtel bych se zeptat zda je mozne udelat 2 pipe do jednoho procesu a
: to tak ze jednu pipe napojim na stdin a druhou na stdout procesu a
: ja pak poslu data do jedne pipe a vysledek si prectu z druhe pipe.
: Nejake priklady jsem nasel, ale koncily tim, ze slo jednou zapsat a
: jednou precist a konec. Ja bych potreboval vicekrat za sebou zapsat
: a precist. Cele se to snazim udelat v C a nejak se mi nedari. Kdyz
: chci jen cist, nebo jen psat tak pouziju funkci popen a uplne bez
: problemu.
: 
: Nemate nekdo s timto zkusenosti?

	Hlavni zadrhel je skryty v tom, jestli poznate, kdy presne
chcete zapisovat a kdy cist. Cili jestli napriklad na cteci strane
je nejak poznat "konec zpravy". Pokud ano, melo by fungovat normalne
otevreni obou rour, vytvoreni potomka, zavreni nepouzivanych koncu rour
na obou stranach, a pak komunikace, ktera ale musi byt takova, abyste si byl
jisty, ze data dostanete ven z procesu (cili pouzivat primo POSIX.1
open(2), write(2), apod., anebo dusledne volat fflush(3) pri pouziti stdio).

	Pokud by to cele melo bezet paralelne, musite se vzdy umet
nejdriv zeptat, jestli mate cist nebo zapisovat. Coz lze udelat pres
select(2), poll(2), epoll(2) nebo neco takoveho. V tom pripade bych
doporucoval nepsat si to cele sam, ale cele to zapouzdrit do nejake
predpripravene knihovny s udalostne rizenou smyckou. Ja mam dobre zkusenosti
s libev (jak v C, tak v Perlu), udalostne rizena smycka je treba taky
v Glib.

	A pak bych jeste zvazil nahradu dvou rour za jeden socketpair(2).
Nebo pokud jde opravdu spis o zpravy nez o nestrukturovana data, tak jsou
tu jeste POSIX nebo SystemV message queues (mq_overview(7), pripadne msgget(2)
a dalsi).

Kdyztak se ptejte.

-Y.

-- 
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| http://www.fi.muni.cz/~kas/                         GPG: 4096R/A45477D5 |
> That's why this kind of vulnerability is a concern: deploying stuff is  <
> often about collecting an obscene number of .jar files and pushing them <
> up to the application server.                          --pboddie at LWN <


Další informace o konferenci Linux