[OSy] testovani

[Vojtech Horky]

Dobrý den.

Dne 7.11.2012 09:40, Pavel Herrmann napsal(a):
> On Tuesday 06 of November 2012 21:10:33 Petr Tůma wrote:
>> 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 ?
> OK, tak je to asi jen o mojem zvyku.
> zaporna cisla mi prijdou lepsi nez kladna, protoze kladna muzou znamenat
> uspech (pocet provedenych operaci), a zaporna chybu. u funkci tyou OK/chyba je
> to pak jen pro konzistenci
Poznámka pod čarou: tuto sémantiku má např. getc_try().

>>> 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".
> "Funkce zrusi zadane (bezici) vlakno. Vlakno, ktere ceka na ukonceni ruseneho
> vlakna, je odblokovano."
>   z toho sem si vyvodil ze kdyz zadne neceka (protoze se rozhodne cekat az za
> 100 let) tak je vlakno zabite a uklizene.
> vytvari to race v synchronizaci (thread_join vrati EKILLED nebo EINVAL podle
> toho co se zavola prvni), na druhou stranu zamezi tomu aby se mnozily zabita
> vlakna na ktera nikdo neceka (coz by asi slo vyresit tim ze si u attached
> vlaken sleduji kdo je vytvoril a periodicky kontroluju ze jeste zije)
Možná by bylo vhodné podívat se na to z trochu větším "nadhledem". 
Myslíte, že je ok, pokud máte attached vlákna, na které nikdo nečeká?

A ten race EINVAL/EKILLED lže vyřešit tak, že provádíte automatický 
úklid až v okamžiku, kdy nikdo nezná identifikátor toho nebohého vlákna.

S pozdravem
- Vojtěch Horký

>
>> 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.
> "davno" se vztahovalo hlavne k testu, kde je simulovana mezera 1s (coz trva
> nekolikrat dele). jako rozumny interval pretrvani mrtveho vlanka bych videl
> treba protoceni planovace (ktere se mi hodi treba k tomu ze uklid se neprovadi
> urcite na zivem vlakne).
>
> diky
> Pavel Herrmann
>
>
> _______________________________________________
> OSy mailing list
> OSy at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/osy