Сравните Pharo vs Go

Кстати, а почему Go, а не Erlang (например)?

Зеленые нити (Process, BlockClosure>>#fork(At:)), семафоры.

"Concurrent Programming in Pharo" by Yuriy Tymchuk [<a href="http://pillarhub.pharocloud.com/hub/Uko/concurrentProgrammingInPharo" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpillarhub.pharocloud.com%2Fhub%2FUko%2FconcurrentProgrammingInPharo\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG6S1ZH7ETSqk9trYb1oGTrjX4kiQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpillarhub.pharocloud.com%2Fhub%2FUko%2FconcurrentProgrammingInPharo\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG6S1ZH7ETSqk9trYb1oGTrjX4kiQ&#39;;return true;">http://pillarhub.pharocloud.com/hub/Uko/concurrentProgrammingInPharo].

Promises и Futures — по вкусу

В рамках одного образа все это на одном процессоре/ядре. Вроде бы что-то там было для организации (эффективного?) обмена данными между образами (общая память?), но сейчас не нашел — могу вообще бредить по этому поводу :)

Ну, и не забываем учитывать это: <a href="https://blog.golang.org/concurrency-is-not-parallelism" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://blog.golang.org/concurrency-is-not-parallelism&#39;;return true;" onclick="this.href=&#39;https://blog.golang.org/concurrency-is-not-parallelism&#39;;return true;">https://blog.golang.org/concurrency-is-not-parallelism  ;)

--

Best regards,

Dennis Schetinin

чт, 21 мар. 2019 г. в 23:56, Александр <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="EnAPCnZlAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">gen...@...>:

Переучиваюсь на Go...

Плююсь и матюкаюсь ) но продолжаю жрать кактус...

//много разных причин... даже сложно обсуждать.., но вот Go... и ничего особо с этим не поделать (сейчас)

Мне интересно, как решено "параллельное"  програмирование в PHaro?
что то есть, это ясно... можно форкнуть процесс с неким приоритетом...
Но очень мало информации обо всём этом плавает на поверхности..

--
--
<a href="http://groups.google.ru/group/sugr" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;" onclick="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;">http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес <a href="javascript:" target="_blank" gdf-obfuscated-mailto="EnAPCnZlAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">sugr+uns...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

У "типичных" Smalltalk'ов (VAST/VW/Pharo) нити ST-процессов "зелёные", что не помогает утилизации ядер многоядерных процессоров. Поэтому [для утилизации N ядер] выходят из положения, запуская M виртуальных машин (M >= N), одна из которых является координатором других (или некоторые из которых является координатором других). Cincom для этого написала framework под названием Polycephaly. "Зато" у Instantiations есть image components (IC), которые можно грузить в shared memory, т.е., они оказывабтся общими для разных VM и так можно потытаться сэкономить ОЗУ. Координатором/балансиловщиком может служить что-то не smalltalk-чье, наподобие Apache.

С другой стороны, если происходит работа со сложными математическими вычислениями или длительными запросами к базам данных, логично переложить основную работу на кого-то ещё, более подходящего, вызывая функции из DLL и получая готовый или почти готовый результат. Тут может быть очень полезен Multihread FFI. Пока некая зелёная нить ждёт ответа от вызванной функции, в это время может выполняться другая зелёная нить. Так мы можем иметь множество работающих (на разных ядрах одновременно) функций.

В VAST и VW такое есть уже десятки лет. А что с Pharo творится - я даже банально не в силах читать их maillist.