Názory k článku
Ľahké vlákna pre JVM
-
-
kimec (neregistrovaný)
Predchodzia implementacia je z roku 2013, t.j. pred Java 8 a lambdami. Je za tym ten isty clovek, co aj za aktualnou implementaciou.
Predchodzia implementacia funguje tak, ze modifikuje bytecode cez agenta alebo AOT.
Aktualna implementacia bude na nizsej urovni aj s podporou vo VM.
-
Přijde mi, že to řeší problém, který neexistuje. Jaká je režie stojícího vlákna v OS, čekajícího na I/O?
Proč je takový problém mít v OS v takovém stavu tisícovku vláken?
Argument, že mohou v jednu chvíli běžet naráz a totálně odrovnat plánovač tak to jsem řešil semaforem, který následoval ihned po I/O operaci a který zajistil, že skutečný počet současně běžících vláken bude třeba jen 10
-
Viz C10k problem. Týká se to velkých veřejných serverů s velkým počtem příchozích spojení. Tam nechceš mít tolik vláken v OS, kolik máš spojení.
(na druhou stranu je trochu komické, když to lidi někdy řeší i u intranetu pro malou firmu a trvají na použití praktik a technologií, které jsou vhodné pro velké veřejné servery :-)
-
kimec (neregistrovaný)
Od 2013 vraj mame uz C10M.
Tak ci onak, riesenie skutocneho problemu (na vytazenom serveri) alebo pseudo problemu (v pripade maleho intranetu) sa da elegantne skryt za rovnaku abstrakciu. -
Kolemjdoucí (neregistrovaný)
Separátní stack je pravda, ale paměti je dnes možno mít v serverech spoustu takže to nepovažuji za velký problém - navíc na stacku se stejně drží data patřící danému spojení která je stejně je potřeba někde v paměti mít. Co ale myslíte pojmem separátní TLS? Není to jen podmnožina dat na stacku?
