Komunikace mezi pthread vlakny

Stanislav Meduna stano-cznews na meduna.org
Sobota Duben 12 21:46:42 CEST 2003


On Sat, 12 Apr 2003 18:07:36 +0000 (UTC), Pavel Kankovsky wrote:

: A proc je writer tak blby, ze po kazdych deseti bajtech zkousi select(),  
: misto aby mel na te roure zapnuty non-blocking, nacpal tam, co se do ni
: vejde, a select() udelal az pote, co se buffer ucpe a on se musi uspat a
: pockat na jeho vyprazdneni? Resp. pokud dela select() kvuli jinym vecem,
: proc nema pro rouru vlastni buffer takove velikosti, jak potrebuje?

Pretoze nepovazuje za rozumne pridavat do programu zlozitost
kvoli minimalizacii volani jadra, ktore su obvykle na Linuxe
lacne - mohlo by to totiz vypalit aj naopak. Pretoze si autor
myslel, ze ked sa kazdy druhy tyzden diskutuje o tom, ako
o 2% zrychlit scheduler, v ktorom obvykle pocitac stravi 0.1%
casu, ze obycajna rura pouzita uplne korektnym sposobom nesposobi
statisice context switchov za sekundu. Pretoze optimalizacia
sa robi az potom, ked program v zasade chodi, inak nebude
hotovy nikdy (co sice netrapi mnoho open source projektov,
ale firmy zvycajne ano). A vobec, aby bolo o com pisat :-)))


Ak si spravne spominam, nas problem bol vtedy program, ktory
mal pre komunikaciu (ktorej bolo viac druhov) vzdy samostatny
thread. Dovodom bolo to, ze konzument tychto dat nevedel
zarucit spracovanie v rozumnom case, zatial co komunikacny
thread musel niekedy reagovat v definovanom casovom intervale.

Takze vela threadov obsluhovalo komunikaciu s klientami a obvykle
bolo vysledkom tejto komunikacie poslanie dat spracovatelskemu
threadu. Na tuto komunikaciu bola pouzita nejaka fronta,
pochopitelne korektne zamykana.

Lenze strcit spravu do fronty je jedna vec a zobudit prijemcu
vec druha. Kedze pokial viem nie je mozne sucasne cakat
na POSIX-ove synchronizacne primitivy, filedeskriptor
a casovac (navyse portabilne, neslo iba o Linux), bola
zvolena cesta najmensieho odporu a pipou sa povedalo,
ze sa nieco zmenilo a treba to spracovat.

Potom som urobil performance-test a nestacil som sa cudovat...

Ja som tu architekturu nevymyslel ani neimplementoval, ale
nevidim na nej nic zasadne chybneho. Rozhodne to nie je prvy
ani posledny program, co to tak robi.

Mas sice uplnu pravdu, ze dobry kod s tym ma pocitat, ale
rovnako ma pocitat jadro s tym, ze bude mat klientov
zapisujucich do pipy po malych kuskoch so selectom medzi
nimi.

: Tedy puvodne ta diskuse byla u toho, ze mezi dvema thready existuje nejake
: uzke a jednoduche rozhrani (nebo tak nejak), coz si zrovna nepredstavuju  
: jako neco, cim se cpou stovky MB za sekundu. :)

Uzke a jednoduche z hladiska poctu sposobov, ako nim poslat
data, nie z hladiska sirky pasma :-)

Zdravi
-- 
                                Stano



Další informace o konferenci Linux