FEL ČVUT vyvinula robotickou stavebnici pro mladé programátory. Stavebnice Brian byla navržená speciálně pro potřeby populární Robosoutěže. Jde ale také o samostatný produkt, který si může koupit každý fanoušek robotiky a programování od 10 let, ideální je i pro střední školy jako výuková pomůcka. Jádro stavebnice tvoří programovatelná řídicí jednotka, kterou vyvinul tým z FEL ČVUT ve spolupráci s průmyslovými partnery. Stavebnici
… více »Ubuntu bude pro testování nových verzí vydávat měsíční snapshoty. Dnes vyšel 1. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Netgate oznámila vydání nové verze 2.8.0 open source firewallové, routovací a VPN platformy pfSense (Wikipedie) postavené na FreeBSD. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 6.16 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Tor Browser byl povýšen na verzi 14.5.3. Linux na verzi 6.1.140. Další změny v příslušném seznamu.
Člověk odsouzený za obchod s drogami daroval letos ministerstvu spravedlnosti 468 kusů kryptoměny bitcoin, které pak resort v aukcích prodal za skoro miliardu korun. Darováním se zabývá policejní Národní centrála proti organizovanému zločinu (NCOZ). Deníku N to potvrdil přímo ministr spravedlnosti Pavel Blažek (ODS). Podle resortu bylo nicméně vše v souladu s právem.
Svobodný a otevřený multiplatformní editor EPUB souborů Sigil (Wikipedie, GitHub) byl vydán ve verzi 2.5.0. Stejně tak doprovodný vizuální EPUB XHTML editor PageEdit (GitHub).
Na základě národního atribučního procesu vláda České republiky označila Čínskou lidovou republiku za zodpovědnou za škodlivou kybernetickou kampaň proti jedné z neutajovaných komunikačních sítí Ministerstva zahraničních věcí ČR. Tato škodlivá aktivita, která trvala od roku 2022 a zasáhla instituci zařazenou na seznam české kritické infrastruktury, byla provedena kyberšpionážní skupinou APT31, veřejně spojovanou se zpravodajskou službou Ministerstvo státní bezpečnosti (MSS).
Google Chrome 137 byl prohlášen za stabilní. Nejnovější stabilní verze 137.0.7151.55 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 11 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán AlmaLinux OS 10 s kódovým názvem Purple Lion. Podrobnosti v poznámkách k vydání. Na rozdíl od Red Hat Enterprise Linuxu 10 nadále podporuje x86-64-v2.
Byl vydán Mozilla Firefox 139.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 139 je již k dispozici také na Flathubu a Snapcraftu.
Běžící blákno, které může takto rychle získat zámek ...
struct mutex { atomic_t count; spinlock_t wait_lock; struct list_head wait_list; };Jádro pudla je v tomto nižším patře = v kernelovém mutexu. Všimněte si položky "struct list_head wait_list" - to je nějaký spojový seznam "čekatelů na zámek". Uvnitř páru volání mutex_lock()/mutex_unlock() existují dvě cesty: rychlá a pomalá. Pomalá cesta bere spinlock a hraje si s wait_listem (seznam čekajících procesů) = při mutex_lock() se vlákno do seznamu zapíše, při mutex_unlock() se vyškrtne. Naproti tomu rychlá cesta uvnitř mutex_lock() za příznivých okolností jenom "proletí", nepřidává se do wait_listu = nebere spinlock, pouze si atomicky (s podporou CPU) dvakrát sáhne na položku count. Podobně uvnitř mutex_unlock(). Za příznivých okolností, konkrétně když o mutex soupeří dvě vlákna, a to ještě na konci delší "dávky" soupeřících vláken:
Jádro pudla je v tomto nižším patře = v kernelovém mutexu.Strucne receno, mutex_lock() v jednom threadu uspeje drive nez skonci mutex_unlock() v druhem a ten druhy stale pristupuje k interni mutexove strukture. Pokud se na takove chovani podivam z hlediska konvencni semantiky posixovych mutexu (tedy pokud by se tak chovali userspace mutexy), tak mi to jako zavadne neprijde (primarni cil - vzajemne vylouceni kodu *uvnitr* mutexove sekce - je zajisten), akorat mutex_destroy() by musel vzit spinlock a tim se ujistit, ze paralelni mutex_unlock() uz skoncil. To by mohlo byt i adekvatni reseni pro kernelove mutexy.
delete
kdekoliv mimo destruktor smart pointerů pokládám za velmi špatný kód* a race conditions dealokací opět dobře řeší smart pointery používající atomický reference counter. Zde je to zesložitěné tím, že se tam snaží aktivně spouštět jiné vlákno, ale s něčím takovým se v user space setkáte jen výjimečně.
* Schválně za jak dlouho přijdete na to, že tohle leakuje?
class Socket { public: Socket() { if (!connect()) throw std::exception(); } bool connect() { return false; } }; class Test { public: constexpr size_t BUF_SIZE = 4096; char *buf; Socket sock; Test() : buf(new char[BUF_SIZE]()) {} ~Test() { delete[] buf; } }
sock
), tak se nezavolá tělo destruktoru; nakonec to je logické, objekt se ještě nevytvořil, a tak není co ničit. C++ v takovém případě volá destruktory všech již zkonstruovaných členů a předků (pokud by Test
měl předka, tak jeho destruktor se zavolá), zde tedy program zavolá destruktor buf
, jenže to je char *
, který se sám nedealokuje. Pokud by buf
byl smart pointer, tak jeho destruktor tu paměť uklidí.
S výjimkami není problém, pokud dodržujete RAII, tedy že každý zabraný zdroj má vlastní „hlídací“ objekt, který jej v destruktoru uvolní. A tohle pravidlo právě vede k tomu, aby delete
používaly akorát smart pointery (a výrazně zjednodušuje hlídání zdrojů oproti C ~Test() try { ⋮ // Volání funkcí, které mohou vyhodit výjimku, kromě destruktorů — tam by si to měl řešit ničené objekty } catch (...) { if (std::uncaught_exception()) // Případně nějaké logování, pokud vás to zajímá return; // catch blok, kterým končí konstruktor či destruktor, má implicitní rethrow }
noexcept
, je potřeba to zrušit:
~Test noexcept(false)
To je syntaxe ve stylu: „Půjdu na nákup ne.“ To snad museli vymyslet Francouzi.Spíš lidi z Cisca
no shutdown
)
Ale ono zrovna v tomhle případě to je namístě, u drtivé většina destruktoru je noexcept
vhodný.
delete
jsem od té doby, co delete
u kódu, který spravuji, smí používat jen smart pointery, neviděl.
Jádro není v C++ hlavně proto, že v roce 1991 byla podpora C++ dost mizerná. A taky proto, že v jádře bývá problém s implementací výjimek a RTTI, tak se to tam nepoužívá, čímž se C++ snižuje na C with classes. A to už pak rovnou jde psát v C.
Tiskni
Sdílej: