В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Scala User Group

2402 membersпожаловаться на группу
2021 August 26

AS

Artem Sokolov in Scala User Group
хотя в целом сейчас подумал что если сделать exclusive shared как выше скидывали, и сделать его на max long, и саму блокировку делать на пустой операции а не на той которую запускаю - то да, будет очень похоже
источник
20:43пожаловаться#1

S

Simon in Scala User Group
Не могли же они написать "Да, мы видели те бенчмарки. Нет, мы не бдем делать как в котах, потому что коты сломаны - вот пример". Пришлось растекаться мысью по древу
источник
20:44пожаловаться#2

ZM

ZLoyer Matveev in Scala User Group
все равно пруфов никто не пишет на конкурентный код

одну багу нашли, еще 5 не нашли

скала не сильно то ушла от жаваскрипта в помощи разработчику в конкурентном коде
источник
20:45пожаловаться#3

S

Simon in Scala User Group
Проблема с "закрытием". Если операция закрытия должан дожидаться всех уже работающих внутри барьера, то семафор с "бесконечно много пермитов" - идеальное решение.
источник
20:45пожаловаться#4

AS

Artem Sokolov in Scala User Group
наоборот не должен
источник
20:45пожаловаться#5

S

Simon in Scala User Group
Тогда не понятен его смысл. Если кто-то уже вошел, то он продолжит работу с уже закрытым барьером. Зачем такой барьер может понадобиться?
источник
20:46пожаловаться#6

AS

Artem Sokolov in Scala User Group
чтобы приостановить входящий поток
источник
20:47пожаловаться#7

S

Simon in Scala User Group
гм... сигнал?
источник
20:47пожаловаться#8

λ

λoλdog in Scala User Group
Ну и сделай latch на stm
источник
20:47пожаловаться#9

S

Simon in Scala User Group
Ref с событиями на изменение
источник
20:48пожаловаться#10

AS

Artem Sokolov in Scala User Group
а есть такой? в зио?
источник
20:48пожаловаться#11

AS

Artem Sokolov in Scala User Group
условно самое семантически близкое было бы сделать
isOpenRef :Ref[Boolean]
но не понятно как сделать isPausedRef.await(isOpen => isOpen) . который если в условии true - идет дальше, если false - "подписывается" на изменения ref и перевычисляет на каждое изменение, пока не получит true и не пойдет дальше
вот нету у рефов такой штуки
источник
20:50пожаловаться#12

S

Simon in Scala User Group
есть, ищу
источник
20:50пожаловаться#13

λ

λoλdog in Scala User Group
TRef
источник
20:51пожаловаться#14

AS

Artem Sokolov in Scala User Group
хм, stm...
источник
20:52пожаловаться#15

S

Simon in Scala User Group
Бредовое решение: взять ZHub буленов с размером 1 и ждать на нем true.
Чтоб заблокировать - пушнуть false
Разблокировать - пушнуть true
источник
20:57пожаловаться#16

λ

λoλdog in Scala User Group
Ух
источник
20:58пожаловаться#17

λ

λoλdog in Scala User Group
Ну с tref такая же почти Истрия
источник
20:59пожаловаться#18

λ

λoλdog in Scala User Group
Делать get.collect
источник
20:59пожаловаться#19

S

Simon in Scala User Group
Но вообще Ref[Option[Promise[Unit]]] обернуть во что-то и будет не хуже =)
источник
21:00пожаловаться#20