Zpracovani signalu procesem

[Ing. Pavel PaJaSoft Janousek]

Dalibor Toman wrote:
> procesu, stava se, ze i v threadech jsou blokujici operace (recv()  a
> spol) preruseny (EINTR), pripadne thready zacnou vyvadet divne

	Predevsim, jakekoli blokovaci operace skonci s EINTR, zahadou pro mne v 
tuto chvili je, zda-li se tak stane pouze a jenom v jednom threadu (tedy 
v tom, ktery se bude venovat obslouzeni signalu) nebo vsech threadech, 
ktere dostanou CPU behem zpracovavani obsluhy signal handleru....

> Dotazy:
>  - je normalni ze zaslani signalu na pid hlavniho procesu ma vliv na
>    thready? Lze tomu nejak zabranit?

	IMHO ano, signaly byly staveny na akce per proces. Jejich implementace 
IMHO nevi naprosto nic o vlaknech a tedy jejich obsluhu provede 
nedefinovane prvni vlakno, ktere se dostane k CPU, rozhodnout o tom 
nemuzete.

!!! Pokud to co pisu neni pravda, rad bych se dozvedel neco noveho...:-)

>  - pokud v threadu signal prerusi recv() muze mit vliv na chovani
>    threadu pri vstupu do zamklych kritickych sekci (pthread_mutex)?
>   (pozn: problem s recv() neni problem vyresit pomoci
>   MSG_NOSIGNAL)

	IMHO muze - pokud vezmu, ze pres recv - tedy blokujici operaci - 
provadim treba nejakou signalizaci (vzdalene mi to pripomina automaticky 
resetovane udalosti ve Win32), pak kdyz obsluhuji signal, ve skutecnosti 
uz v te kriticke sekci nejsem, IMHO jsem totiz presne za ni, protoze:

a) proces/vlakno obdrzi od jadra (?) a knihoven ret. kod EINTR
b) proces/vlakno se venuje obsluze signalu

	a tedy neni duvod proc jiny zablkovany vlakno by nemohlo do teto 
kriticke sekce vstoupit.

>  - co muzu a co nesmim v obsluze odchyceneho signalu? (zapisuju do
>    message logu syslogem)

	Co muzete ve smeru k vlaknum nevim, resp. neodvazuji si to popisovat, 
protoze a) pisi zasadne spise 'forkove' systemy, b) mohl bych si 
vymyslet, protoze bych vychazel z teoretickych zakladu a nikoli 
konkretni prakticke implementace jak knihovny pthread, kterou zrejme 
pouzivate, tak implementace v jadre (navenek se totiz jednotlive thready 
tvari jako jednotlive procesy, ne vzdy je to vyhodne).

PS: Signaly sice jsou brany jako jeden z IPC prostredku, ovsem doba 
jejich vzniku (a ted mam na mysli predevsim tzv. 'bezpecne' signaly, ne 
jeji predchozi implementace (oznacovana jako nespolehlive signaly)) s 
necim jako thready nepocitala. Rovnez je to podobne jako s vyjimkamy v 
Jave a C++ - daji se pouzit ruzne, ale ne vsechny pouziti jsou vhodna. 
Signal je specialni a hlavne malo se vyskytujici udalost (i kdyz mohu 
napr. SIGALRM generovat kazdou sekundu:-) - jako casovac nekdy docela 
dobry...), ktera by mela byt systemove obslouzena. Silne doporucuji se v 
  uzivatelskych aplikacich komunikaci pres signaly, pokud je to mozne, 
vyhnout a radeji sahnout po jinem IPC prostredku - napr. Message Queue a 
Semaforech.

	Tak mne jeste napada - nastaveni handleru provadi ve Vasem pripade 
ktery tok? - hlavni pred vytvarenim vlaken nebo jedno konkretni vlakno? 
Doufam, ze se nemylim, ale tyto 'systemove' tabulky sdili cely proces, 
resp. vsechny virtualni lokace jsou smerovany na jednu fyzickou.

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------