abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 15:33 | Humor

    PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují

    … více »
    NUKE GAZA! 🎆 | Komentářů: 2
    včera 14:33 | Nová verze Ladislav Hagara | Komentářů: 0
    včera 12:33 | Zajímavý projekt

    FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.

    NUKE GAZA! 🎆 | Komentářů: 4
    14.3. 22:55 | IT novinky

    Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.

    Ladislav Hagara | Komentářů: 1
    14.3. 21:33 | Nová verze

    Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.

    |🇵🇸 | Komentářů: 2
    14.3. 13:00 | Humor

    Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.

    NUKE GAZA! 🎆 | Komentářů: 12
    14.3. 00:44 | IT novinky

    Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.

    Ladislav Hagara | Komentářů: 7
    14.3. 00:33 | IT novinky

    V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.

    Ladislav Hagara | Komentářů: 5
    13.3. 12:33 | Zajímavý projekt

    MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.

    NUKE GAZA! 🎆 | Komentářů: 17
    13.3. 03:55 | Bezpečnostní upozornění

    Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.

    Ladislav Hagara | Komentářů: 2
    Které desktopové prostředí na Linuxu používáte?
     (16%)
     (7%)
     (0%)
     (11%)
     (29%)
     (2%)
     (5%)
     (1%)
     (13%)
     (24%)
    Celkem 1088 hlasů
     Komentářů: 26, poslední 12.3. 08:56
    Rozcestník

    Dotaz: SIGCHLD v asynchronim programu

    9.3.2011 17:32 alexfa | skóre: 7
    SIGCHLD v asynchronim programu
    Přečteno: 449×
    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
    Ales Teska | Twitter: @alesteska | TeskaLabs | GitHub

    Řešení dotazu:


    Odpovědi

    Řešení 2× (xHire, alexfa (tazatel))
    9.3.2011 18:25 Sten
    Rozbalit Rozbalit vše Re: SIGCHLD v asynchronim programu
    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.
    9.3.2011 19:34 alexfa | skóre: 7
    Rozbalit Rozbalit vše Re: SIGCHLD v asynchronim programu
    Bingo - dekuji.
    Ales Teska | Twitter: @alesteska | TeskaLabs | GitHub
    10.3.2011 00:18 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: SIGCHLD v asynchronim programu

    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.

    10.3.2011 09:52 alexfa | skóre: 7
    Rozbalit Rozbalit vše Re: SIGCHLD v asynchronim programu
    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.
    Ales Teska | Twitter: @alesteska | TeskaLabs | GitHub
    10.3.2011 13:18 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: SIGCHLD v asynchronim programu
    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.

    10.3.2011 08:46 Kojot
    Rozbalit Rozbalit vše Re: SIGCHLD v asynchronim programu
    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.
    10.3.2011 09:57 alexfa | skóre: 7
    Rozbalit Rozbalit vše Re: SIGCHLD v asynchronim programu
    Ano, to je dobra otazka ... v tomto konkretnim pripade by thready asi vse zbytecne komplikovaly ale v jinem (pristim) projektu toto urcite vyuziji ;-)
    Ales Teska | Twitter: @alesteska | TeskaLabs | GitHub
    10.3.2011 13:30 Sten
    Rozbalit Rozbalit vše Re: SIGCHLD v asynchronim programu
    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 ;-)

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.