On Monday 10 February 2003 17:52, Florin Malita wrote: > On Mon, 2003-02-10 at 15:30, Dorin Lazar wrote: > > Producator-ul (la randul lui un consumer) trebuie sa citeasca > > datele dintr-un socket. Bit-rate-ul este foarte mare, de aceea > > trebuie sa fie cat mai rapid. Regula spune ca nu am voie sa am > > apeluri blocante acolo. > Apeluri blocante la trimiterea datelor catre consumator presupun, nu > vad de ce nu ar putea face blocking read de pe socket. Imposibilitatea de a realiza faptul ca a expirat o perioada te timp (folosirea lui SIGALRM e exclusa, scriu o biblioteca).
> Q: chiar ai nevoie de 2 threaduri? de ce nu procesezi datele in > acelasi thread care le citeste? > ... > Asa ca eu iti recomand sa incerci in felul urmator: maresti buffer-ul > socket-ului si procesezi datele pe masura ce le citesti (rafale, > whatever). Situatia ramane cam aceeasi (oricum producatorul trebuia > sa astepte pana consumatorul facea loc in buffer, nu?) dar scapi de > IPC si latente scheduler. Pana la urma asta a fost solutia pe care am adoptat-o. Ideea initiala era ca sa facem un singur fir pentru citiri de pe socket (thanks to select/poll) si fire de prelucrare. Ar fi avut sens (oarecum) dar, vazand rezultatele testelor cu realitatea, deloc eficienta. Oricum, merita incercat :) IPC-ul nu era totusi implicat - am folosit obiectele de sincronizare din pthreads (mutex/conditie). Latenta la scheduler as fi putut sa o "pacalesc" daca ar fi existat posibilitatea sa fac multitasking cooperativ - mi-am amintit insa de un articol mai vechi dintr-o revista in care autorul se intreba de ce nu exista multitasking cooperativ in Linux (si explica si care erau motivele oficiale). Ar fi fost insa interesant - un lucru interesant pe care POSIX nu il stie. -- Dorin "sp00ky" Lazar, programmer Registered Linux user #162515 -- Pentru dezabonare, trimiteti mail la [EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'. REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
