[so] tema 4 retaliates

[Dorin Cristescu]

I'm ba-ack!, djoo' miss me?

Salve

Imi pare rau sa fiu pisalog dar tema 4 ma cam
exaspereaza.
Da, intr-un tarziu m-apuc de tema 4(va rog, no
judgement!), si ma cam impotmolesc. In linux in plus!!
Si daca tot ma sprintenesc la spartul targului, m-am
gandit ca macar s-o fac cat de cat corecta, fara
compromisuri si neglijari. N-am avansat peste situatia
tip 'a'.

Sa redau firul considerentelor:

Lasand la o parte porcarelele cu, intr-o tema care se
vrea esenta, culmea asincronicitatii, ls-ul ala, pe
care numai asincron nu poti sa-l faci - din ce-am
vazut eu nici sistemul nu ofera vreun apel nonblocant
din punctul asta de vedere, nici stat, nici readdir
etc. - m-am lovit de urmatoarele consideratii:

-tinand cont de constrangerea ca un numar oarecare de
threaduri sa poata functiona, ce bloca folosirea a
unui semnal pentru fiecare thread, a reiesit ca se
insista la folosirea semnalelor imbogatite.
-foarte frumos, m-am gandit. Analizand mecanismul am
ajuns la situatia urmatoare: cum informatia utila din
semnal se transmite asincron, putand deci veni in
rafala, una dupa alta etc., revine ca trebuie folosita
o sincronizare in handler. Cam infiorator. Orice fel
de sincronizare, chiar si cea recomandata de FAQul
LinuxThreads, anume cu semafoare, presupune o situatie
producator-consumator. Adica si consumatorul se
blocheaza asteptand produsul, DAR SI producatorul se
blocheaza dupa ce produce informatia, pentru a nu o
suprascrie, eventual, inainte de a fi preluata.
Situatia cu implementarea unei cozi, nu eludeaza
folsoriea sincronizarii, cu atat mai mult cu cat
pthread_* nu sunt async signal safe. Si nici nu pot
chema malloc din handler. Si un vector ar trebui
tratat cu o sectie critica, in timpul unui handler(!)
deci foarte instabil.
-celelalte variante propuse in faq, parca expre nu se
ocupa cu semnale inbunatatite. Nici sigwaitul nu
ruleaza handlerul, deci nu avem acces la informatia
despre operatia aio care se semnaleaza.
Ar mai fi solutia ca in handler sa anunt direct
threadul interesat, dar 1) pthread_kill incep e cu
"pthread" si 2) oricum pthread_kill nu permite
informatie in semnalul trimis.
Ma gandisem sa workaround asta redefinindu-mi
propriile pthread kill , trimitand cu sigqueue; si
pidul aflandu-l facand getpid in threadul respectiv,
dar nu prea e cuser, si nu cred ca a fost calculata
sau agreata de artizanii linuxthreads aceasta idee, ca
altfel puneau si ei functia de aflare a pidului
threadului cu thread_id cutare accesibila. Deci dead
end.

Daca astept sincron semnale cu sigsuspend ajung la
problema linuxthreadurilor:
1- daca toate threadurile accepta semnalul, n-am nici
o garantie cine-l executa
2- daca dedic un thread semnalelor, in restul
blocandu-le, (cum ma gandeam sa fac pana la problema
de mai jos) din care sa dispatchuiesc/dirijez in
modalitate ortodoxa mesaje catre workeri (cu conditii,
pipeuri samd) apare bugul recunoscut de autorul
linuxthreads, ca un semnal care ajunge intregului
proces, daca pica in ograda unui thread(proces) care-l
blocheaza, nu mai iese de acolo, si asteapta sa fie
deblocat, fata de specificatia posix care cere ca
orice thread care nu-l blocheaza sa il preia.

In plus peste asta, problema care m-a facut sa reies
pe postament:
revin la transmiterea informatiei utile din handler
catre threaduri - 
o situatie adorabila: ma blochez in handler dupa ce
trec informatia produsa in variabila globala de
comunicare cu threadul destinatar - deci asta inseamna
ca blochez tot threadul care s-a intamplat sa preia
semnalul; si intru iar cu o alta informatie, destinata
aceluiasi worker. Deja semaforul e luat de anterior,
deci blochez inca un thread. Asa mai departe pana
termin toate threadurile si nu mai poate functiona
nimeni!!
Mai rau: daca se intampla chiar ca threadul destinatar
sa trateze semnalul, blocandu-l in handler, nu mai am
cum sa deblochez handshakeul de transmitere a
informatiei(adica sa spun producatorului ca "gata, eu
consumatorul am preluat informatia"), fiindca sunt
deja blocat asteptand ca tot eu sa preiau informatia,
si-mi creez un deadlock de toata frumusetea.

Se cam inchide cercul.
Este cumva tema prea pretentioasa pentru mecanismele
oferite de linux?

Sa nu ma luati cu condescendente malitioase ca s-a mai
raspuns anterior la asa ceva, ca ma cam indoiesc sa fi
tratat cineva asa de despicand firu'-n saptispe
situatia.


As aprecia un raspuns prompt ca .... tic-toc,
tic-toc..

Thank you all, that's it for me.
Goodnite everybody!

=====
-------

Trece lebedele-n zare,
Eu ma uit, ele dispare


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250