[OSy] testovani

Petr Tůma petr.tuma at d3s.mff.cuni.cz
Tue Nov 6 21:10:33 CET 2012


Dobry den,

> 1) proc se testuje navratova hodnota na EINVAL (a podobne)? obvykle
> se (IMHO) pouziva spise -EINVAL?

Castecne je to otazka stylu, viz predmet kolegy Buleje "Doporucene 
postupy v programovani" :-)

Co je obvyklejsi je docela tezko zodpoveditelna otazka. Napriklad ve 
Windows API funkce casto jako chybu vraceji 0 nebo NULL a vlastni 
chybovy kod se zjistuje az pres GetLastError, numericky je kladny. V API 
Linuxu je mnoho chybovych kodu take numericky kladnych, nektere funkce 
je vraci takto (napriklad pthreads), jine vraci 0 nebo -1 jako indikaci 
chyby a nastavuji errno na deklarovanou (kladnou) konstantu, jinde jsou 
ale deklarovane i zaporne chybove konstanty (napriklad pro getaddrinfo), 
v kernelu naopak vyrazne prevazuje vraceni konstant s opacnym (zapornym) 
znamenkem, i kdyz sem tam se najdou vyjimky.

Napiste mi, co myslite ze je lepsi ?

> 2) jaka konfigurace (msim.conf) bude pouzita pri testovani?
> uniprocesor nebo multiprocesor?

Cituji ze zadani: "Pro zakladni zadani postacuje, pokud budou veskere 
operace korektne synchronizovany a odladeny na systemu vybavenem jedinym 
procesorem."

V soucasne dobe se testuje pouze splneni zakladniho zadani.

> 3) jsou dodane testy spravne? presneji mam problem s testem thread2,
> kdy se pozaduje EKILLED pri join() na vlakno ktere je uz davno zabite
> (proti tomu kdyz je vlakno zabite behem join(), jak popisuje zadani)

Uprimne receno, vasi interpretaci v textu zadani nevidim, text rika 
"EKILLED pokud bylo vlakno zruseno volanim funkce thread_kill", nikde 
tam nevidim to "behem join".

Ale v tomto pripade je myslim lepsi nechat otazku vykladu zadani stranou 
a zamyslet se spis nad tim, jak by vami navrhovana semantika mela presne 
fungovat. Umel byste ji popsat ? Zejmena mi jde o ten vyraz "davno": 
melo by se vracet EKILLED na vlakno zabite "nedavno", nicmene jeste pred 
zavolanim join ? Co vlakno zabite tesne na zacatku volani join ? Zkuste 
mi napsat vasi definici.

Dekuji, Petr Tuma




More information about the NSWI004 mailing list