[so] examen SO

[Alexandru Goia]

Buna ziua
Intr-o foaie de examen se pune problema utilizarii semafoarelor UNIX peste handleruri de semnale UNIX.
Nu agreez modelul de I/O bazat pe semnale (unul din cele 5 modele UNIX de I/O, vezi UNIX/Stevens/Teer/Solaris/Kernighan - UNIX), dar in locul lor indic in loc de semnale multiple indicatii pe un named pipes. (IPC/FS/UNIX).
De ce nu agreez ? Fiindca in historica, semnalele erau rare, HZurile erau mici, accesele erau putine. Intre timp,s-a inventat nanosleep()-ul si alte minunatii 10 at power (-9), 10 at power (-12), EXCLUSIV pe platforma linux kernel, sustinut de MIT/GCC/GLIBC, sistem Linux pe care il vad, simt, consider ca imatur, incoeziv si FARA STRUCTURA DE SISTEM DE OPERARE !!!! precum System V, Sun 4, Solaris 5, UNIX-urile mature, productive si comerciale, si chiar elemente de Berkeley Unix.
Sa presupunem ca consideram constructia unui web server, pe principii mature si clare. (Ideatica martiala/securitate/performanta).
In loc sa fac 10, 10, 10, 10, 10 ... 10 x 5 accese la o arhiva web de 10 MB/GB,
deci in loc sa fac 500/512 de accese,
mai bine fac 1000/1024 de accese la "plinirea vremii", cand contorul up() al semaforului urca pana la maxim !
Deci fac "blow-ul" pe multifd(), multifd fiind multiplexarea conceptului de file/network file descriptor,
EXACT CAND SE UMPLE PAHARUL !!!
Nu fac putin si la fiecare,ci fac TOTUL LA TOATE, fie ca o scriu ca stl vector<nfd>  cu typedef nfdfie ca o fac ca multifd() / UNIX cu acces scriere prin cod sursa kernel.
Despre largimea benzii IO pe retea, si alte chestiuni externe, placi, performanta, device drivere interne/externe,Linux / FreeBSD, FaceBook/FreeBSD network/memory/etc performance stack, c10k / m10k problems, WhatsAppperformance de la 1.5 mill nfd la 2.5/3 mill nfs connexiuni SIMULTANE (vezi de ce exista SCTP, iar NU MP TCP),cu alta ocazie.
Cu respect,WarmWildWolf , aka Alexandru Goia
m0ft / omega software / cis/ics / rack * / uni'x school (unifficial)
2019 January

Long Live UNIX !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20190126/f94657eb/attachment.html>