Ľahké vlákna pre JVM

Takže fibery? S tím jsem si hrál na Linuxu taky (setcontext/get­context), ale je tam pořád context switch, ušetří se tak akorát na vytváření vláken a pro to stačí thread pool.

Java ma uz zopar rokov user space work stealing fork join scheduler. Ten sa dnes pouziva pri paralelnych streamoch. Predchodzia implementacia fiberov ho pouzivala tiez a myslim, ze ho bude pouzivat aj tato nova.

Dejavu. Nápadně to připomíná goroutiny z Go..

Nechapu smysl te otazky.. Goroutiny jsou součástí std lib od roku 2007. Nekdo to vymyslel a napsal. Zcela prekvapive..

CSP, Tony Hoare et al.?

Fakt ne. Goroutiny se od vzory CSP lisi.

https://golang.org/doc/faq#csp

Java vstupila do roku 2014.

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.

捷克門戶網站
寫捷克語

チェコ語と一緒、西スラブ語­族の一つなので、君分からないわけないわけもない。

Naučte se normálníé písmo, Chachaři.

так уверен

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.

Režie stojícího vlákna je mizivá. Problém je, když těch stojících vláken je deset tisíc či když rychle vznikají a zanikají.

Pametova rezie ale uplne miziva neni - napr. separatni stack a TLS.

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?

Tahle paměťová režie je stejná u fiberů a víceméně i korutin.

Vsak to pouzivat nemusis. Ale podle me se to hodi i na mensi projekty - pokud je to dostatecne jednoduche na pouziti (e.g. nic to nestoji), tak proc ne?