Apple na své vývojářské konferenci WWDC24 (Worldwide Developers Conference, keynote) představil řadu novinek: svou umělou inteligenci pojmenovanou jednoduše Apple Intelligence, iOS 18, visionOS 2, macOS Sequoia, iPadOS 18, watchOS 11, …
Vyšla nová verze XMPP (Jabber) klienta Gajim, která přidává podporu reakcí pomocí emoji (XEP-0444: Message Reactions) a citace zpráv (XEP-0461: Message Replies). Přehled dalších vylepšení je k dispozici na oficiálních stránkách.
Po po téměř roce vývoje od vydání verze 5.38 byla vydána nová stabilní verze 5.40 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 75 vývojářů. Změněno bylo přibližně 160 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Po dvou měsících vývoje byla vydána nová verze 0.13.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 73 vývojářů. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
Zdravim vospolok
Mam program v c++, 3 vlakna, jedno vlakno prijma pakety zo siete, druhe vykonava cinnost, tretie tiez nejaku cinnost. V kazdom vlakne sa obcas pouziva funkcia usleep. Problem nastava, ze na pravdepobone novomkerneli sa tie vlakna locknu a vsetko zostane visiet a nic sa nerobi.
Vyzera to ako keby sa tie usleepy lockli v kerneli alebo co. System Fedora 36, kernel-6.2.11-100.fc36.x86_64. Napada niekoho nieco?Tu je z callstack debugera:
Thread 1
#0 __kernel_vsyscall () at arch/x86/entry/vdso/vdso32/system_call.S:72
#1 0xf792043b in __GI___clock_nanosleep_time64 (clock_id=<optimized out>, flags=0, req=0xff94d3b8, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:62
#2 0xf7925fe9 in __GI___nanosleep64 (rem=0x0, req=0xff94d3b8) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#3 __GI___nanosleep (req=0xff94d404, rem=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:42
#4 0xf7961fe3 in usleep (useconds=1000) at ../sysdeps/posix/usleep.c:31
Thread 2
#0 __kernel_vsyscall () at arch/x86/entry/vdso/vdso32/system_call.S:72
#1 0xf796bcec in __libc_recv (fd=4, buf=0xf51fec3c, len=10, flags=0) at ../sysdeps/unix/sysv/linux/recv.c:30
Thread 3
#0 __kernel_vsyscall () at arch/x86/entry/vdso/vdso32/system_call.S:72
#1 0xf792043b in __GI___clock_nanosleep_time64 (clock_id=<optimized out>, flags=0, req=0xf13302a8, rem=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:62
#2 0xf7925fe9 in __GI___nanosleep64 (rem=0x0, req=0xf13302a8) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#3 __GI___nanosleep (req=0xf13302f4, rem=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:42
#4 0xf7961fe3 in usleep (useconds=60000000) at ../sysdeps/posix/usleep.c:31
Jako další postup navrhuji:
sleep()
ve všech podobách. Nikdy nemá smysl a jen škodí. Nepatří do userspace. Jen v kernelu může mít (velmi) omezené uplatnění. Pak zkusit celý problém reprodukovat.…pozastaveni se normalne pouziva…
Ale prd. Že někdo píše špatný software, to ještě neznamená, že „se“ takové postupy používají běžně všude.
…to vede k vetsi propustnosti…
Nevede to ani omylem k větší propustnosti; tak tenhle svět nefunguje. Vede to (někdy, výjimečně, při pečlivém načasování) k nižší latenci.
Nejvyšší propustnost přijde v situaci, když bude konzument zcela saturovaný producentem, nikdy se neuspí a bude žrát nějakou (ideálně) neblokující frontu. Tam sleep()
opravdu (ale opravdu) nebude hrát roli.
Především, program v userspace nemá co/proč pollovat. (Pokud nedělá něco ultra-hardwarově-nízkoúrovňového, jenže v takovém případě není v userspace, takže nic.) Polling v různých podobách a granularitách se už děje automaticky jako součást prakticky všech UNIXových synchronizačních primitiv. Žádný (kni)hovní zamykací mechanismus (například z pthread.h
) nezačne bezhlavě volat po context-switchi, aniž by se napřed pokusil o spinlock atd. atp.
Taková↑ (kni)hovní implementace je většinou dobře odladěná a optimalizovaná pro danou platformu, umí použít lock elision, kde to jde (jo, to bývaly časy, když ještě fungovaly TSX), a nějaký program v userspace by se neměl neomaleně pokoušet dělat znova něco podobného.
Pokud bych opravdu potřeboval pollovat (a to bych nepotřeboval), mám k tomu spousty lepších prostředků než sleep()
. timer_create()
a timer_settime()
například, kdybych se chtěl nechávat vyrušit z téměř libovolného blokujícího spaní. Nebo spoustu „timed
“ variant funkcí, jako sigtimedwait()
, sem_timedwait()
, pthread_cond_timedwait()
atd. atp.
Tiskni Sdílej: