[so] egal incarcate

[Octavian Purdila]

------------o3NZmg3w1L6b6j9DIGn5Zu
Content-Type: text/plain; format=flowed; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


On Wed, 3 Dec 2003 10:29:20 +0200, Ovidiu Platon 
<ovidiupl@microsoft-lab.pub.ro> wrote:

>
> 	OP> Va primi un 'ready to rock' dupa care va astepta ca procesarea sa 
> se intample efectiv. Daca insa ar fi analizat un pic si ar fi decis ca e 
> mai bine sa porneasca un nou thread, procesarea ar fi putut decurge mai 
> rapid, exploatand la maxim si procesorul si discul;

Dupa ce thread-ul primeste datele, adica asteapta la I/O, el le va trimite 
prin socket, deci
face alta operatie de I/O. Intercalat cu aceste operatii mai executa 10-20 
de instructiuni
masina in care mai faci mici chestii administrative, ca de exemplu scoate 
cererea din coada.

Aparent avem aici o latenta de 10-20 instr care pentru un numar mare de 
cereri creste liniar, astfel
incat avem o latenta de N*(10-20) instructiuni, corect? Nope. Pentru ca, 
latenta de 10-20 instr se
compenseaza  prin faptul ca in timp ce asteptam la I/O putem executa 
celelalte 10-20 instr.
Asa ca lucrurile stau destul de bine atunci cand se foloseste un singur 
thread, pentru valori ale lui N relativ
mari. Pentru exemplificare vedeti programul atasat (si tineti cont de 
faptul ca printf face pana la urma
un apel de sistem, deci e relativ costisitor).

> daca ar fi decis ca  nu e  nevoie de inca un thread, ar fi avut loc 
> celalalt scenariu. Sigur,

Daca se folosesc mai multe thread-uri, apare o latenta la comutarea 
thread-urilor. Astfel incat nu
are sens sa folositi mai multe thread-uri decat daca sunt prezente in 
sistem mai multe procesoare. Pentru
asta exista parametri pentru server.

>
> 	OP> Mie exprimarea asta mi se pare cam radicala si eu unul as fi 
> evitat-o, macar din politete daca nu din alte motive. Daca sugestia mea 
> a fost deplasata, ma asteptam la o explicatie de genul "Uite, pentru 
> aplicatia asta e mai bine sa faci cum e in cerinta pentru ca...", nu un 
> raspuns cliseu de tipul "Ce parte din <trebuie> nu intelegi"...
> 	

Daca mailul l-ar fi scris altcineva, asa as fi procedat. La genul de 
mailuri pe care
le trimiti insa, am considerat ca are sens sa imi exprim clar parerea fata 
de atitudini
de genul "tampenia aia de MinGW", "am impresia ca aici invatam, nu gandim" 
care
sunt afirmatii gratuite ce nu au nici o sustinere.

In plus, afirmatii de genu asta nu au ce cauta pe lista, si daca este 
cazul o sa renunt la
compania celor ce in continuare, in mod repetat nu respecta regulile.

tavi

------------o3NZmg3w1L6b6j9DIGn5Zu
Content-Disposition: attachment; filename=aio.c
Content-Type: application/octet-stream; name=aio.c
Content-Transfer-Encoding: 8bit

#include <aio.h>
#include <stdio.h>

int main(int argc, char **argv)
{
	int fd=open(argv[1], O_RDONLY), i, tmp;
	char buff[64000];
	struct aiocb aio = {
		aio_fildes: fd,
		aio_offset:0,
		aio_buf:buff,
		aio_nbytes:64000,
		aio_reqprio:0,
		aio_sigevent: { 
			sigev_notify:SIGEV_NONE
		},
		aio_lio_opcode: LIO_READ,
	};
	
	
	aio_read(&aio);
	
	for(i=0; i<=1000000; i++) {
		printf("\r %d %d", i, tmp=aio_return(&aio));
		if (tmp) {
			printf("\n");
			return 0;
		}
	}
	
	return 0;
}

------------o3NZmg3w1L6b6j9DIGn5Zu--