Dotaz: Linux - Vlakna

[Jarda]

Zdravim,

Mel bych dotaz na zasilani signalu v linuxu. Jde mi o toto. Pokud napriklad vlakno hojne vyuziva IO operace tak se mu jaksi tezko da poslat signal.

Napriklad kdyz date do smycky cout << "Neco << endl.

Jde nejak definovat aby signal byl dorucenej v kazdym pripade ?

 

Dekuji za odpoved.

 

Odpovědi

[rastos]

Pokiaľ viem, tak pri vykonaní volania signal() sa nastaví príslušný bit v nejakej maske v štruktúre, v ktorej si jadro udržuje informácie o procese. Bity tejto masky sú skontrolované jadrom v momente, kedy sa jadro rozhodne priradiť CPU tomuto procesu. Aby signál nebol doručený, musel by process bežať a nebyť prerušený ničím iným (ani iným procesom ani jadrom samotným) a ak by bol prerušený, tak nedostať znova CPU - čo mi pripadá značne nepravdepodobné. Skôr by som pátral po tom, aký druh signálu posielaš, či nie je blokovaný, či je obslúžiteľný atď. Alebo je reč o úplne iných druhoch signálov - takých ako posiela pthread_cond_signal()?

[Messa]

I když má vlákno zrovna rozběhnutý nějaký syscall, zasláním signálu je tento syscall přerušen, signál obsloužen a knihovní funkce tento syscall obalující obvykle vrací něco jako EINTR nebo vrátí méně dat, než o kolik byly požádány (viz man stránky). Mám na mysli signály zasílané např. příkazem kill.

Asi by bylo lepší podroběji popsat situaci, ukázat kód...

[Michal Kubeček]

Tohle ale platí jen pro některé syscally, typicky ty, u kterých se dá očekávat, že se na jejich dokončení může dlouho čekat. To, co tazatel popisuje, ale odpovídá read() nebo write(), které mezi ně zrovna patří.

[Radek Miček]

Tomu nerozumím, v manu se např. u read píše:

If a read() is interrupted by a signal before it reads any data, it shall return -1 with errno set to [EINTR].

[Michal Kubeček]

Čemu nerozumíte? Vždyť jsem přece jasně napsal, že read() zrovna patří mezi syscally, které se chovají tak, jak Messa tvrdí. Pouze jsem upozorňoval, že se tak nechovají všechny syscally, jak by se z jeho příspěvku mohlo zdát.

[Radek Miček]

Aha, já to pochopil opačně, omlouvám se.

[Ash]

No nejste sám, já taky :) Až po cca sedmám přečtení jsem si všiml že tam není

ale odpovídá read() nebo write(), které mezi ně zrovna nepatří

ale

ale odpovídá read() nebo write(), které mezi ně zrovna patří

[Ivan]

Hmm a neni jeste nejak zkomplikovano tim, ze zarizeni v unixu jsou rozdelana na rychla a pomala? Na neco takoveho si matne zvpominam z prednasek z Unixu, ale uz si nedokazu presne vzpomenout cim se ta zarizeni lisi.

 

[oroborus]

a nie nahodou: "zariadenia v Unixe su rozdelene na znakove a blokove" ?

[Michal Kubeček]

Je-li řeč o klasických signálech, tak signál vždy zpracuje některý thread procesu, přičemž to, který to bude, můžete ovlivnit nastavení masek jednotlivým threadům pomocí pthread_sigmask(). Pokud např. nastavíte signál jako blokovaný všem threadům kromě jednoho, pak ho zpracuje právě ten jeden. Druhou možností je použít pthread_kill() a poslat signál přímo konkrétnímu threadu.

[Jarda]

No ukazka kodu je jednoducha.

Napriklad:

 

#include <iostream>

 

using namespace std;

 

int main()

{

while(true)

{

coud << "Hello World" << endl;

}

}

 

a zkuste si to zabit pres ctr+c trva to pekne dlouho.

O co mi jde.  Pisu managera kterej bude obsluhovat vlakna a nastavovat jim urcitej cas, ktery budou mit na vyrizeni sitovyho pozadavku.

Udelal sem to takto. V hlavni smycce managera ma sleep(1) a tam projde kontainer tech vlaken ktery obsluhuje. Pokud vyprsel cas posle mu signal. Ja ho v tom vlakne muzu odchytnout obslouzit zavrit socket atp.

Jenze pokud tech vlaken bude v manageru vic a budou se chovat tak jako viz nahore tak ten signal vubec neposlu respektive se neobslouzi.

Nejaky napad jak to udelat lip ?

 

Diky 

 

 

 

 

[Ivan]

Hmm nejsem si jistej jestli jsou signaly to pravy reseni pro komunikaci mezi vlakny. Zkus se podivat na knihovnu apr (apache portable library). Ta to sice resi trochu slozite, ale zase to funguje i na woknach.

 

[ivan]

Kouknete se na tohle. apr knihovna to vlastne resi dost neumele. Komunikaci mezi vlakny je mozne vyresit bez signalu, bez syscallu, bez zamku. Cele je to pak mnohem rychlejsi. http://www.gamedev.net/community/forums/topic.asp?topic_id=511635

Implementace na linuxu je bohuzel dost pracna.

[Michal Kubeček]

a zkuste si to zabit pres ctr+c trva to pekne dlouho.

U mne bez pozorovatelného zpoždění. Ale i v případě, že to máte pomalé, problém vůbec nemusí být (a téměř jistě není) v tom, že by thread nedostával signály.

[rastos]

a zkuste si to zabit pres ctr+c trva to pekne dlouho.

Tu je ale problém v tom, že dlho beží ten výpis na obrazovku. Skús to presmerovať do súboru - koľko potrvá od stlačenia Ctrl+C po skončenie procesu. Ešte markantnejšie to je keď to pustíš na stroji, na ktorý si prihlásený po sieti.

[pht]

Jak bylo řečeno, to zpoždění určite nebude tím že by nějaký signál nedošel. IMHO prostě nestíhá vypisovat terminál ty řetězce. Zkuste přesměrovat výstup Vašeho programu do /dev/null a uvidíte jak to funguje. Zařídit zaslání signálu za 1 sekundu umí i systém samotný (viz funkce alarm a spol.), na to nepotřebujete zvláštní vlákno. Navíc pokud se to čekání týká nějaké odezvy na socketu nebo souborovém deskriptoru, tak postačí obyčejný select nebo poll a obejdete se bez signálů úplně.

[Messa]

Pokud se nejedná o práci s diskem, asi by pomohl select/pselect.

Jinak v tomhle případě to bude spíš pomalým renderováním terminálu (jak již bylo zmíněno)