Google na své vývojářské konferenci Google I/O 2024 představil řadu novinek. Keynote byl věnován umělé inteligenci (DeepMind, Gemini, Responsible AI).
V Gitu bylo nalezeno 5 zranitelností. Opraveny jsou ve verzích 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 a 2.39.4. Útočník může připravit repozitář tak, že při jeho klonování (git clone) může dojít ke spuštění libovolného kódu.
Virtualizační softwary VMware Workstation Pro a VMware Fusion Pro jsou nově pro osobní použití zdarma. Softwary VMware Workstation Player a VMware Fusion Player končí.
Linuxová distribuce Endless OS (Wikipedie) byla vydána ve verzi 6.0.0. Přehled novinek i s náhledy v příspěvku na blogu, poznámkách k vydání a také na YouTube.
Byl vydán Mozilla Firefox 126.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vylepšena byla funkce "Zkopírovat odkaz bez sledovacích prvků". Přidána byla podpora zstd (Zstandard). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 126 je již k dispozici také na Flathubu a Snapcraftu.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 11.0. Přehled novinek v aktualizované dokumentaci.
Byla vydána nová verze 24.0 linuxové distribuce Manjaro (Wikipedie). Její kódové jméno je Wynsdey. Ke stažení je v edicích GNOME, KDE PLASMA a XFCE.
Byla představena oficiální rozšiřující deska Raspberry Pi M.2 HAT+ pro připojování M.2 periferii jako jsou NVMe disky a AI akcelerátory k Raspberry Pi 5. Cena je 12 dolarů.
V Praze o víkendu proběhla bastlířská událost roku - výstava Maker Fair v Praze. I strahovští bastlíři nelenili a bastly ostatních prozkoumali. Přijďte si proto i vy na Virtuální Bastlírnu popovídat, co Vás nejvíce zaujalo a jaké projekty jste si přinesli! Samozřejmě, nejen českou bastlířskou scénou je člověk živ - takže co se stalo ve světě a o čem mohou strahováci něco říct? Smutnou zprávou může být to, že provozovatel Sigfoxu jde do
… více »Kam asi vede IllllIllIIl.llIlI.lI? Zkracovač URL llIlI.lI.
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: