[OSy] Potiz s testy prvniho zakladniho zadani

[Martin Decky]

Hezky den,

testy skutecne predpokladaji, ze datovy typ thread_t je ve skutecnosti 
ukazatel na strukturu (ovsem to, ze jde o ukazatel, je v API skryto). 
Funkce thread_create() strukturu vlakna take dynamicky alokuje. 
Standardni implementace teto abstrakce tedy vypada nasledovne:

struct thread {
     /* ... */
};

typedef struct thread * thread_t;

Vase reseni, kdy struktura vlakna obsahuje pouze handle pro identifikaci 
jine struktury fyzicky popisujici vlakno, znamena jednu uroven abstrakce 
navic a s tim testy zkratka nepocitaji. Tento datovy typ by se dle meho 
nazoru nemel jmenovat thread_t, ale treba thread_id_t, a API funkce pro 
fyzickou praci s vlakny by nadale mely pouzivat fyzickou strukturu 
vlakna thread_t. Typ thread_id_t se naopak vyborne hodi pro rozhrani 
systemovych volani.

Pokud skutecne trvate na tom, aby struktura thread_t obsahovala pouze 
handle, muzete stale pouzit typedef jako je uveden vyse, i kdyz to 
rozhodne neni elegantni reseni. Dalsi moznost je rezignovat na striktni 
typovou kontrolu a typ thread_t deklarovat jako void *, ktery vsak 
nebude interpretovan jako ukazatel, ale jako handle.

Rozhodne se take nebranime tomu, abyste si testy upravili a tam, kde se 
nyni pouziva vypis thread_t pomoci %p, byl vypis thread_t.id pomoci %u. 
Smysl testu to samozrejme neovlivni. Prosim, nezapomente takovou zmenu 
testu zdokumentovat.

Stale si myslim, ze neni duvod, aby si kernelove funkce vzajemne 
predavaly jen handle vlakna a ne vlakno samotne. Nicmene pokud Vase 
implementace s jednou abstrakci navic ma nejake vyhody, ktere ted 
nevidim, prizpusobte tomu zbytek infrastruktury podle sveho nejlepsiho 
uvazeni.

M.D.