concurrent-ruby - библиотека и Си расширение интерпретатора CRuby

Хорошее библиотечное решение для создания сопрограмм и CSP (https://blog.golang.org/share-memory-by-communicating), акторов, высокоуровнего многопоточного и асинхронного программирования на Ruby, заменяющее использование модуля Fibers.

С одной лишь оговоркой - native threads в рамках процесса интерпретатора поддерживаются с версии 1.9, но многопоточное программирование возможно в рамках потока исполнения байт-кода интерпретатором, т.к. GIL в CRuby пока ещё существует и интерпретатор способен исполнять байт-код в разных потоках последовательно, т.е. в один момент времени исполняется/интерпретируется только один поток байт-кода.

GIL - это мьютекс в конвейере интерпретатора, контролирующий доступ к общей памяти и исключающий взаимный единовременный доступ нескольких потоков к ней.

Это необходимо для исключения доступа нескольких потоков к общей памяти (thread safety, shared mutable state, shared mutable memory) и состояния взаимоблокировки потоков (dead-locks) или гонки (race condition) потоков за доступ к ресурсам одного блока памяти, что порождает утечку памяти, т.к. оба потока активны и GC не освобождает их общую память.

Более того, всё ещё сложнее - GIL присутствует в интерпретаторах скриптовых динамических языков до стих пор ещё и потому, что автоматическое управление памятью, GC и существующий в эталонных интерпретаторах механизм подсчёта ссылок (RC) очень хорошо оптимизированы под однопоточную сборку мусора в куче, но очень плохо проработан механизм подсчёта ссылок в нескольких потоках и многопоточная сборка мусора.

Также блокировка потоков механизмом GIL используется для immutable гарантий доступа к памяти при вызове низкоуровневого кода через FFI API/ABI интерфейсы, например расширений интерпретатора на Си.

JRuby и Rubinius сейчас свободны от GIL.
В JRuby используется модель акторов и Java Threads, модуль Fibers заморожен и удалён в пользу использования Java Threads.
В Rubinius используется своя модель доступа потоков к памяти также на базе механизма акторов.

concurrent-ruby единственная библиотека, гарантирующая thread safety и работающая одинаково во всех интерпретаторах Ruby - CRuby (MRI/YARV), JRuby, Rubinius.

https://github.com/ruby-concurrency/concurrent-ruby

https://ruby-concurrency.github.io/concurrent-ruby/

https://docs.google.com/document/d/1pVzU8w_QF44YzUCCab990Q_WZOdhpKolCIHaiXG-sPw/edit

Ссылки:
http://www.csinaction.com/2014/10/10/multithreading-in-the-mri-ruby-interpreter/

http://merbist.com/2011/10/03/about-concurrency-and-the-gil/

http://merbist.com/2011/10/18/data-safety-and-gil-removal/

http://merbist.com/2011/02/22/concurrency-in-ruby-explained/

https://github.com/mperham/acting_lessons

https://wiki.python.org/moin/GlobalInterpreterLock

CPython, CRuby, CLua, Node.js/V8 - все реализации интерпретаторов для разных языков используют мьютексные примитивы для реализации GIL и управления памятью потоков

У Юкихиро Матсумото есть стремление вовсе убрать GIL для для управления памятью потоков из эталонного интерпретатора CRuby в третьей версии языка.

https://www.youtube.com/watch?v=48iKjUcENRE

https://twitter.com/yukihiro_matz/status/495219763883163648

https://medium.com/@franzejr/ruby-3-mri-and-gil-a302577c6634

Релиз Debian 9, codename "Stretch"

Релиз посвящён памяти основателя проекта Debian, Яну Мердоку.

http://ftp.debian.org/debian/doc/dedication/dedication-9.0.txt

https://blog.docker.com/2015/12/ian-murdock/

https://bits.debian.org/2015/12/mourning-ian-murdock.html

https://www.debian.org/News/2017/20170617

http://distrowatch.com/?newsid=09865

http://distrowatch.com/debian

Previous posts:
https://t.me/technologique/973
https://t.me/technologique/974
https://t.me/technologique/975
https://t.me/technologique/976

Next releases codenames:
https://t.me/technologique/911
https://t.me/technologique/384

Почему Kotlin достоен внимания и чем он интересен.

https://medium.com/@octskyward/why-kotlin-is-my-next-programming-language-c25c001e26e3

Kotlin язык практический и прагматичный, не академический, выросший из потребностей индустрии разработки на JVM и компании JetBrains, накопившей в этой индустрии огромную экспертизу.

Kotlin comes from industry, not academia. It solves problems faced by working programmers today.

Now there is Kotlin, and with it the last traditional pain associated with the Java ecosystem is gone. You can write code that’s more expressive and more concise than even a scripting language, but with way fewer bugs and with way better performance.

https://try.kotlinlang.org

http://kotlinlang.org/docs/resources.html

http://blog.paralleluniverse.co/2015/06/04/quasar-kotlin/

Как неверный выбор технологий для задачи приводит к значительным финансовым потерям.

О некорректной реализации библиотечных функций в языках программирования для работы с генераторами случайных чисел и к чему приводит слабая система типов языков и слабая проверка типов данных в динамических языках в разработках для финансовой индустрии и криптовалют.

https://medium.com/@octskyward/type-safety-and-rngs-40e3ec71ab3a

Крис Лэттнер покинул подразделение Tesla Autopilot Software.

В своём аккаунте в Твиттер Крис пишет, что работа ему не зашла по интересам. 😁😂

https://twitter.com/clattner_llvm/status/877341760812232704

http://nondot.org/sabre/Resume.html

Для ОС Redox, написанной на языке Rust, удалось произвести bootstrapping - скомпилировать всю ОС и ядро под самой ОС Redox.

Для этого под ОС были портированы компиляторы GCC toolchain и LLVM Compiler Toolchain, для портирования компилятора языка Rust - rustc.

https://www.redox-os.org/news/gsoc-self-hosting-1/

Разработчики компилятора OCaml Compiler Toolchain при оптимизации циклов в генерируемом компилятором коде программ на практике нашли баги при исполнении процессорами Intel блоков инструкций в коротких циклах в многопоточном режиме Hyper-Threading. Проблема касается процессоров Intel последних поколений, Skylake и KabyLake.
Обновления микрокода для некоторых моделей процессоров уже готовы для дистрибутива Debian.

https://lists.debian.org/debian-devel/2017/06/msg00308.html

http://www.opennet.ru/opennews/art.shtml?num=46762

Линус Торвальдс и Дирк Хоундл (VP, VMWare) - беседа на открытии первой ежегодной конференции LC3 China (LinuxCon + ContainerCon + CloudOpen) в Пекине.

https://www.youtube.com/watch?v=0rsx65_wjoE

https://www.lfasiallc.com/linuxcon-containercon-cloudopen-china

https://www.linuxfoundation.org/announcements/linuxcon-containercon-cloudopen-comes-to-china-for-first-time-2017

https://www.linux.com/blog/event/LC3-China/2017/linux-foundation-brings-3-new-open-source-events-china

Состоялся релиз языка и компилятора Crystal 0.23.0.

Появилась поддержка CSP многопоточности (как в Go, но со вкусом Ruby 😉) на базе сопрограмм, каналов и тред-пулов для маппинга программных потоков (нитей, fibers, green threads) на системные потоки в thread-pool'е процесса программы.
Для сборки компилятора требуется LLVM 3.8.

https://github.com/crystal-lang/crystal/releases/tag/0.23.0

Иерархическая классификация типизированного лямбда-исчисления, на базе лямбда куба Барендрегта, и его поддержка в языках функционального программирования:
https://gist.github.com/andrcmdr/7121c3d9eb83f06785d8055a5c3604a3


PS:
В январе-феврале этого года я прошёл курс Ерика Мейера по Haskell на EDX:
https://www.edx.org/course/introduction-functional-programming-delftx-fp101x-0

А после прослушал дополнительно курс практических лекций по Haskell:
https://www.youtube.com/watch?v=02_H3LjqMr8

https://www.youtube.com/playlist?list=PLwwk4BHih4fj2fxUuHEfvwNN84LALr5R3

Всем, кто интересуется и изучает концепции функционального программирования - очень рекомендую! 👍

Дискуссия с Крисом Лэттнером по дальнейшему развитию языка Swift на конференции WWDC 2017.

https://youtu.be/4qX1o-4W0HM

https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel/

Видеозапись дискуссии можно также найти здесь:
https://news.realm.io/news/wwdc-2017-swift-panel/

Языку Swift и его компилятору сейчас действительно не хватает безопасной и внятной модели работы с потоками и их памятью, для удобного создания многопоточных приложений, т.к. на уровне языка нет поддержки работы с потоками (на базе сопрограмм или акторов) и асинхронным неблокирующим вводом-выводом (futures and promises, async/await, event-based async). Есть только фреймворк Grand Central Dispatch (GCD), который использует thread-pool pattern и мьютексную блокировку доступа к памяти потоков для управления критическими секциями. При использовании GCD код превращается в бесконечную пирамиду вызовов ("handler pyramid of doom", "call-back/closures hell").
Таким образом Swift не обеспечивает thread safety и код использует общую память для потоков (критические секции, shared mutable memory, shared mutable state), а без обеспечения thread safety про Server API (https://swift.org/server-apis/) и применение Swift в разработке ПО для серверных облачных инфраструктур можно забыть.

Ксавьер Лерой, разработчик группы проекта Gallium из института INRIA в Париже, во Франции, один из авторов языка OCaml и основных разработчиков его компилятора и виртуальной машины, рассказал подробности об обнаруженном им баге в процессорах Intel, при отладке оптимизации циклов компилятором OCaml для исполнения генерируемого компилятором кода в многопоточном режиме Hyper-Threading на архитектурах процессоров Intel последних поколений (Skylake и KabyLake).

http://gallium.inria.fr/blog/intel-skylake-bug

http://ocamllabs.io/general/2017/06/26/IntelHyperThreadBug.html

Перевод на русский язык:
https://habrahabr.ru/post/332552/

Oracle создали открытый run-time для контейнеризации в Linux на Rust - проект RailCar.

Проект RailCar создаётся на Rust на базе спецификации OCI (Open Container Initiative Runtime Specification, https://www.opencontainers.org) и претендует на положение серьёзной альтернативы и конкурента Docker, другой реализации спецификации OCI на Golang, от очень серьёзного поставщика облачных систем и решений - Oracle.


https://blogs.oracle.com/developers/building-a-container-runtime-in-rust

https://blogs.oracle.com/developers/three-new-open-source-container-utilities

https://thenewstack.io/oracle-opens-oci-container-runtime


https://github.com/oracle/railcar - run-time для управления контейнерами

https://github.com/oracle/crashcart - инструмент для отладки контейнеров с возможностями загрузки (sideload) в контейнер сторонних образов с исполняемыми файлами

https://github.com/oracle/smith - сборщик образов контейнеров на базе образов OCI или RPM пакетов


https://github.com/opencontainers/runtime-spec - спецификация OCI run-time

https://github.com/opencontainers/image-spec - спецификация образов OCI

https://github.com/opencontainers/runc - реализация OCI, базовый run-time для порождения процессов контейнеров


Причины создания RailCar и почему Go не так хорош для создания run-time для систем конейнеризации:

https://blogs.oracle.com/developers/the-microcontainer-manifesto

https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix


Links:
https://t.me/technologique/971