[OSy] Datovy typ thread_t

[Martin Decky]

> * Prvy pripad vyzaduje nejaku 'konverznu' tabulku (ID->structure pointer, 
> alebo sa napr. priamo alokuje pole struktur), ale vracia vcelku pekne cisla 
> ID threadov (napr. pre debug ucely). Nevyhoda je nevyuzite miesto v pamati (v 
> blbom pripade dost velke mnozstvo nevyuzitej pamati (aj pri recyklacii thread 
> ID)).

Typickym zpusobem, jak minimalizovat tuto nevyhodu, je pouziti nejake
hashovaci tabulky.

> Preto sa chcem opytat, co odporucate pouzit radsej (lepsie skrytie 
> implementacie vs. lepsie vyuzitie pamati) - aby sme zbytocne neprisli o body 
> hned na zaciatku :-)

Ani na tuto otazku neexistuje snadna a jednoznacna odpoved. Cele jadro
se typicky povazuje z hlediska bezpecnosti za jedinou komponentu, takze
veskery kod v nem bezici by se mel z definice chovat "slusne". Coz by na
jednu stranu nahravalo te variante s ukazateli (pricemz datove
struktury, na ktere ukazuji, lze alespon castecne zabezpecit nejakymi
magic hodnotami nebo kontrolnimi soucty).

Na druhou stranu, pokud se pokusime i kernel chapat jako modularni
spojeni vice subsystemu, tak lze na ukor jiste spotreby pameti a casu
prikrocit k lepsimu oddeleni a pouzit identifikatory, u kterych lze
jednoznacne zjistit, zda jsou platne.

> Snad sa nepytam prilis vela - ked tak staci napisat ze "it's up on you" :-) 

To je asi nejpresnejsi .. :) Nechceme Vam zadanim prilis svazat ruce.
Chceme, abyste se nad problemy zamysleli a vybrali jedno z moznych a
principielne spravnych reseni.


M.D.