BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 141 (pdf) a HackSpace 78 (pdf).
Byla vydána verze 2.0.0 programovacího jazyka Kotlin (Wikipedie, GitHub). Oficiálně bude představena ve čtvrtek na konferenci KotlinConf 2024 v Kodani. Livestream bude možné sledovat na YouTube.
Byla vydána nová major verze 27.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Jednoduché je to v případech, kdy máme k dispozici souborové deskriptory. Ty použijeme ve volání select(), poll() nebo epoll() a hned se dozvíme, co se stalo. Problém je ovšem v tom, že tyto deskriptory máme jen pro omezený okruh událostí. Pro mnohé události (asynchronní I/O, časovače, skončení podřízeného procesu atd.) musíme spoléhat na signály - a ty s výše uvedeným nejdou příliš dohromady.Ad asynchronní I/O a deskriptory - píšeš, že jediným skutečně bezpečným způsobem zpracování signálů je volání
sigwait()
. Co je špatně na způsobu, kdy se při zpracování signálu SIGIO pomocí select()
otestují deskriptory a příslušně se zareaguje? (Za předpokladu, že deskriptorů není příliš mnoho)
sigwait()
(a samozřejmě také sigwaitinfo()
a sigtimedwait()
) má tu výhodu, že se zpracuje vždy právě jeden signál (a ostatní zůstávají blokované) a nepoužívá se - není potřeba - asynchronní handler. Při jiném řešení už nastávají komplikace s rozlišováním, které všechny signály vlastně přišly. Tak jako tak tam ale zůstane problém s výkonností, protože select/poll operace je obecně O(n).
int main() { struct sigaction sigakce; void io_sigio (int i); void casovano (int i); ... sigakce.sa_handler = io_sigio; sigfillset (&sigakce.sa_mask); sigakce.sa_flags = 0; sigaction (SIGIO, &sigakce, NULL); sigakce.sa_handler = casovano; sigaction (SIGALRM, &sigakce, NULL); for (;;) {pause();} }Program má jenom reagovat na události - příchod dat ze sítě a periférií a na časovač, takže čeká v nekonečné smyčce. Jestli jsem to dobře pochopil, tak při použití
sigwait()
by program v nekonečné smyčce volal tuto funkci a rozhodoval, jaký signál přišel a jak se zachovat.
Při jiném řešení už nastávají komplikace s rozlišováním, které všechny signály vlastně přišly.To znamená, že když nepoužívám sigwait() a přijde víc signálů najednou, že se některé zahodí a nezpracují? Já měl zato, že se nejprve zavolá obsluha jednoho a pak druhého.
Tak jako tak tam ale zůstane problém s výkonností, protože select/poll operace je obecně O(n).Jasně, proto jsem psal, že předpokládám, že deskriptorů je málo (tento případ rozhodně není to, co je popsáno v blogu - tj. server s mnoha síťovými spojeními, otevřenými soubory apod.)
volatile
(= rychlost dolů). A tak dále.
Jestli jsem to dobře pochopil, tak při použití sigwait() by program v nekonečné smyčce volal tuto funkci a rozhodoval, jaký signál přišel a jak se zachovat.
sigwait()
vrací (resp. zapisuje přes pointer) číslo signálu, který přišel. Funkce sigwaitinfo()
a sigtimedwait()
dělají totéž, ale navíc ještě poskytují další informace (např. identifikátor časovače, PID ukončeného potomka, PID procesu, který zavolal kill()
apod.).
Všechny tyto funkce fungují tak, že se zavolají s blokovanými signály, tyto se uvnitř odblokují, a když přijde první signál (nebo už nějaký čeká), zase se všechny signály zablokují a vyskočí to ven z funkce. To vše atomicky. Pak lze bezpečně a synchronně dělat cokoliv. Takže se to používá tak, že se v nekonečné smyčce volá sigwait()
a vždy se podle čísla signálu zjistí, jaká událost nastala.
To znamená, že když nepoužívám sigwait() a přijde víc signálů najednou, že se některé zahodí a nezpracují? Já měl zato, že se nejprve zavolá obsluha jednoho a pak druhého.Signál se "zahodí" jen v jediném případě - že se jedná o obyčejný (klasický POSIXový, ne-realtime) signál a již nějaký čeká na zpracování. Ovšem když přijde více signálů "najednou" (tedy těsně po sobě), začne se zpracovávat jeden, a pokud ty další nejsou blokované, může kdykoliv začít obsluha jiného (s jiným číslem). Takže to doběhne třeba do půlky handleru a v tu chvíli začne obsluha jiného signálu. Blokace v handleru to úplně neřeší, protože se nemusí stihnout (i když toto není většinou tragédie). Horší ale je, že jsou to pro každý handler 2 syscally navíc, což sežere dost času. Tohle je výhoda
sigwait()
, že takové problémy se nemusejí vůbec řešit.
Tiskni Sdílej: