продолжим наш бложик краткой записью, относящейся к предыдущей.
вот что очень хочется иметь — это потоки по
этому принципу. там про A2, и про то, что многопоточность на самом деле кооперативная, хотя для программиста выглядит как вытесняющая. трюк в том, что компилятор втихую добавляет код проверки некоего счётчика и переключение контекстов в стратегических местах, а реальных потоков всегда столько, сколько в системе процессоров. это позволяет проще контролировать и ресурсы, и места, где переключение на другой поток разрешено. а за счёт этого упрощается и реализация сборщика мусора: ему не надо особо переживать о том, что какой-то поток может прерваться в непредсказуемом месте.
это не сильно хорошо взаимодействует с потоками ОС, конечно (то есть, никак). но это совершенно неважно: свои работают нормально, а потоки во внешних библиотеках всё равно нуждаются в очень нежном обращении.
сами по себе потоки инструмент довольно специфический, требуют внимания и аккуратности как при работе с бензопилой, в которую встроен AI, активно ненавидящий всё живое. поэтому адаптация идей A2 — это на очень далёкую перспективу.
про Active BlackBox я в курсе, и его можно, конечно, попробовать адаптировать тоже — но смысла не вижу. хотя, возможно, когда начну с современным A2, то эксперимент с ABB проведу: как показал опыт — это можно сделать силами одного человека с нуля; а уж имея на руках уже готовую реализацию (пусть и на устаревшей платформе) — будет ещё проще.
в принципе, по гамбургскому счёту потоки нужны в основном там, где есть длительное блокирующее i/o, которое никак не обойти. сейчас это тоже можно организовать, надо только высунуть наружу платформо-независимую обёртку над API создания потоков. а дальше обычная схема: заякореный RECORD с нужными параметрами, фоновый action с проверкой флажка завершения, и колбэк/посылка сообщения. код надо сразу под такое проектировать, конечно. платим прибитым гвоздями минимальным квантом на фоновую операцию (ну, относительно прибитым, неважно в данном случае), так что имеет смысл только для очень долгих операций, или для операций не критичных к тому, что они могут занять 50, например, мсек, хотя завершатся намного раньше. для какого-нибудь DNS resolving, например, нормально. ну, и батчить можно.
тем не менее, потоков с меньшим квантом хочется. может, действительно сначала ABB портировать. короче, джинн опять думать будет — тем более оно не горит.