Přijďte si zasprintovat na Djangu, jiném Python open-source projektu, nebo jen potkat ostatní vývojáře!
… více »Letos v říjnu se v Praze uskuteční hned několik konferencí. Odehraje se zde nově vzniklá konference LinuxDays. K ní se přidá čtvrtý ročník openSUSE Conference, dvanáctý ročník SUSE Labs conference a aby to nebylo málo, přidá se i první ročník Gentoo miniconf. A to vše ve stejné dny a na stejném místě.
… více »Na webu IBM developerWorks vyšel článek o únicích paměti při práci s POSIXovými vlákny. Dozvíte se jak úniky vznikají, jak je detekovat a jak zabránit jejich vzniku.
Tiskni
Sdílej:
Jinými slovy, je prostě dobré vědět o pthread_cleanup_push a pthread_cleanup_pop.
tyhle funkce neznalPozor, s tímhle jsem měl problémy, někde to tu asi bude zahrabaný v dotazech - můžou to být makra a v GCC na linuxu@x86-64 to opravdu makra jsou.
Vlastně to nejsou funkce, ale (konkrétně na Linuxu) makra. To první končí { a to druhé začíná }. Aby to člověk nezapomněl spárovat.
Při použití podmínkových proměnných ve spojení s thread cancellation je tohle naprostá nezbytnost, protože zrušení vlákna při čekání na podmínkovou proměnnou vždy nakonec nechá mutex zamčený. A někdo ho musí odemknout. (V man pthread_cond_wait je o tom celý odstavec.)
Možná to není zajímavé, ale jsou případy, kdy je to nezbytné. Típnout vlákno (pthread_cancel()), které čeká na podmínkové proměnné, prostě nelze nijak jinak než za asistence pthread_cleanup_*(). Jinak ten příslušný mutex už zůstane zamčený a není žádný korektní způsob, jak ho znova odemknout.