Dotaz: SIGCHLD v asynchronim programu

[alexfa]

Dobry den,

narazil jsem v jednom svem projektu na "zajimave" zjisteni, ktere se tyka POSIXoveho signalu SIGCHLD (resp. SIGCLD).

Program je navrzen asynchronne - tzn. ma ve svem jadru smycku, ktera reaguje na udalosti na socketech (select/poll) a vlastni logika je pak napsana jako obsluha techto udalosti. Jednou ze soucasti kodu je take spravce podprocesu - ten pracuje tak, ze na pozadani spusti obecny podprocess (fork a pripadny exec) a to opet v asynchronim modu, tzn. programator si zaregistuje obsluhu udalosti pro spousteny proces a vrati rizeni programu zpet asynchronimu jadru.

Cele to pracuje dle ocekavani a s resenim jsem byl po nejakou dobu spokojen. Pak se bohuzel ale zacaly objevovat chyby spojene se systemovymi volanimi, ktere koncily ve stavu EINTR. Celkem obratem me doslo, ze asynchronne bezici podproces z nejakeho duvodu skoncil a vygeneroval signal SIGCHLD (ktery muj program spravne zachytil a zaradil do fronty udalosti pozadavek na vyzvednuti exit statusu pomoci systemove fce wait a vygenerovani prislusne udalosti OnChildExit). Bohuzel side-efekt k teto udalosti je take preruseni pripadneho systemoveho volani - program sice neni multithreadovany ale diky sve asynchronni povaze muze delat prakticky cokoliv (a to i v knihovne treti strany). Typickym prikladem je operace write, ktera 'neco' zapisuje na disk a je prerusena signalem SIGCHLD ... to 'neco' je samozrejme hodne dulezite a zprostredkovane knihovnou, kterou nemohu opravovat (a i kdybych mohl, tak dle meho nazoru takova zaludnost v reseni nemuze zustat, protoze se bude periodicky vracet a prekvapovat kazdeho novacka ve vyvojovem tymu).

Jako reseni toho problemu jsem zakazal obsluhu SIGCHLD signalu (cimz jsem malicko opustil vody definovane v puvodnim POSIX stadardu). To samozrejme okamzite vyresilo problem s 'pretrhavanim' systemovych volani, nicmene to take znamena, ze jiz nezjistim exit status podprocesu (podproces preskoci fazi 'zombie' a volani funkce wait vraci chybu neexistujiciho pidu). Prakticky to znamena, ze nedokazi zjistit navratovou hodnotu (return code/exit code) podprocesu, jeho ukonceni nastesti aplikace zaregistuje, protoze take dojde uzavreni stdout a stderr descriptoru.

Jak jsem pochopil z par dotazu na Google, toto je stav, ktery nema univerzalni reseni (tzn. v POSIXovem standardu). Bud budu mit zapnuty SIGCHLD a budu moct pouzivat wait a tudiz zachytavat exit status podprocesu ale zaroven pak budu trpet na EINTR chyby, nebo SIGCHLD budu ignorovat a pak nemam cesty jak zjistit navratovy kod podprocesu. Pro uplnost dodam, ze 'synchronni' volani podprocesu (napr. fce system) pracuje normalne.

Moje otazka je, zda nevite o nejakem reseni, jak o exit code neprijit a zaroven se vyhnout EINTR problemu.

Muj napad spociva ve vytvoreni 'wrapperu' - meziprocesu, ktery budu pouzivat mezi vlastnim spoustenym podprocesem a asynchronim parentem a ktery bude pouzivat synchronni exec a posleze komunikovat return code rodici jinou nez signalovou cestou. Toto je ale docela slozite reseni, do ktereho se mi moc nechce, pokud nebudu mit jistotu, ze toto nelze resit jinym, treba i platform-specific resenim. Cilovou platformou je pro me Linux ale reseni by obecne melo fungovat i na Mac OSX ...

Diky, Ales

---

---

Odpovědi

[xHire]

Já jsem tohle řešil tím, že jsem signál zablokoval, nikoliv ignoroval. Systémová volání to nepřerušovalo, ale ukončení childi pěkně čekali na vyzvednutí stavu.

[alexfa]

Bingo - dekuji.

[Michal Kubeček]

Proč tak silná slova - záludnost, překvapovat, problém, trpět? To chování je naprosto standardní a je popsáno snad v každé dokumentaci. Kdo používá syscally typu write() přímo, měl by přece vědět, že mohou vrátit -1 nejen kvůli skutečné chybě, ale i proto, že byly přerušeny signálem (a nemusí to být zdaleka jen CHLD). Řešení existují - od ruční kontroly errno přes makro TEMP_FAILURE_RETRY, použití sigaction() s nastavením příznaku SA_RETRY až po (dočasné) blokování signálu.

Navíc je to chování v řadě situací žádoucí: pokud budete mít např. síťového démona, jehož handler na TERM jen nastaví příznak, na základě kterého se pak vyskočí z hlavní smyčky, tak právě toto chování vám umožní, aby démon skončil hned po obdržení signálu TERM a ne až ve chvíli, kdy se připojí další klient.

[alexfa]

Jen ve zkratce:

• errno a TEMP_FAILURE_RETRY bohuzel spousta knihoven nepouziva - a dale se tento pristup komplikuje, kdyz v reseni sedi napr. pythonova VM
• sigaction se nakonec ukazalo jako "spravne" (ve smyslu kompatibility se zbytkem implementace)

Ad demon - ano, presne toto reseni pouzivam i ja. A stejnou logiku (okamzitou reakci na signal pri cekani v hlavni smycce) potrebuji a mam.

V POSIXu jsem uz nejaky patek nedelal ale rad se k nemu vracim, je to dobre navrzeny standard. Bohuzel si ale uz obcas nepamatuji vsechny souvislosti (v tomto konkretnim pripade si mi zamotal vyznam ignorovani a blokovani signalu) - ale od toho existuji tyto poradny, ne? Pokud jsem pouzil prilis silna slova, tak se omlouvam, snazil jsem se to popsat dostatecne ctive a presne, dle meho nazoru to ucel splnilo - vyvolalo to (zatim) 3 reakce, ze kterych jsem se dozvedel 2 (ehm) zajimave veci, ktere se mi jiste budou hodit a ja za ne dekuji.

[Michal Kubeček]

Pokud jsem pouzil prilis silna slova, tak se omlouvam

Není potřeba se omlouvat, prostě jsem měl z vašeho dotazu pocit, že přerušení přerušitelných syscallů signálem (znovu zdůrazňuji, že se to týká všech signálů, nejen CHLD) považujete za chybu nebo dokonce jakousi "past na programátory". Proto jsem se snažil (v posledním odstavci) naznačit, že existují velmi dobré důvody, proč se systém chová právě takto, a zmínit několik způsobů, jak se s tím (více či méně snadno) vypořádat.

[Kojot]

Je také otázka, jestli to cpát všechno na jedno místo do jedný smyčky. POSIX vlákna mají každé svojí masku na signály, takže i stím je možné si pohrát.

[alexfa]

Ano, to je dobra otazka ... v tomto konkretnim pripade by thready asi vse zbytecne komplikovaly ale v jinem (pristim) projektu toto urcite vyuziji

[Sten]

Napsat dvouvláknovou aplikaci, kde jedno vlákno chytá signály a druhé pracuje, je triviální:

void work()
{
	...
}

int main(int argc,
         char **argv)
{
	...

	sigset_t mask;
	sigfillset(&mask);
	// Blokneme všechny signály, takže se budou doručovat, jen když je čekám
	pthread_sigmask(SIG_BLOCK, &mask, nullptr);
	/* Vytvořím pracující vlákno; nová vlákna dědí masku, takže tohle vlákno
	 * nedostane žádné signály, pokud na ně nebude čekat */
	pthread_t worker;
	pthread_create(&worker, nullptr, &work, nullptr);

	// Čekám na signály
	sigemptyset(&mask);
	sigaddset(&mask, SIGINT);
	sigaddset(&mask, SIGQUIT);
	sigaddset(&mask, SIGTERM);
	... // a další, co nás zajímají
	for (bool running = true; running;) {
		int sig = 0;
		sigwait(&mask, &sig);
		switch (sig) {
		case SIGINT:
		case SIGQUIT:
		case SIGTERM:
			running = false;
			break;
		... // další signály
		}
	}

	... // Oznámíme vláknu, že má skončit, a počkáme na něj
	int ret;
	pthread_join(&thread, &ret);
	return ret; // Hotovo :)
}

A pro komunikaci s druhým vláknem (informaci, že má skončit) můžete využít třeba eventfd — moje oblíbené, je to taková lehká roura, dá se na tom selectovat