потому что между узлами сообщения ходят по сети через udp

это вообще неважно, абстрагируемся за Async<>

если не можешь абстрагироваться, оберни синхронный вызов в async {} :D

для начала сойдёт

возможно, мы немного про разное говорим

очень вероятно

udp => нет понятия "ответ" на сообщения

т.е. тут один воркфоу и разрывается

ну так мейлбоксы это и решают

послал туда запрос, тебе пришёл ответ (возможно)

ну вот мне потребовалось создать запрос удалённому узлу, я написал в сокет, а в это время мне в сокет, который я слушаю, могут писать другие узлы

ты хочешь получать от сервера ченел для ответа, сообщение в ящик с ответом или промиз ответа?

между удалёнными узлами — сообщение в ящик (и каждая пара реквест-респонс пронумерована одинаковым guid типа conversationId)

но локальному клиенту надо отдать промис на ответ

т.е. получается, что локальный клиент вызывает функцию, которая генерит гуид для новой беседы, создаёт реквест к удалённому узлу и ожидает когда-нибудь получить от него в свой ящик ответ с таким же гуидом. как только она его получает — она должна заполнить проимс пришедшим значением

ну я вижу так если клиент и обёртка на клиенте для общения с сервером по UDP сигнатура обёртки чот типа Request -> Async<Response> обёртка - асинхронный блок, который делает чот типа async { do! socket.send data let rec listenLoop = async { let! incoming = socket.listen() if incoming = validData then return incoming else return! listenLoop } return! listenLoop }

в таком случае на каждый реквест, по приходу нового сообщения, будет заниматься тред и смотреть что там пришло

ну это не так работает прям)

асинк тоже через тредпул работает, как и таски

условно есть 1000 активных запросов — приходит что-то в сокет — 1000 раз листнеры проверят это сообщение и только один поймёт, что гуид совпадает и это ответ на именно его запрос

ну это-то понятно, просто все 1000 листнеров отработают

а, я понял

я же запоминаю в хешмапу все активные запросы по guid -> responseProcessor и по приходу сообщения в совкет отдаю только одному обработчику ответа

ну и этот словарь пробрасывается в следующую итерацию мейлбокса

поэтому тут и возникает разрыв воркфлоу

+ в моём случае ответ на один запрос может сильно повлиять на все остальные активные запросы (например, отменить их)

псевдокод одного актора листенера let requestMap = Dictionary<_,_> let actor = mailbox { match! mailbox.Receive() with | AddNewListener (guid, responseChannel) -> requestMap.Add (guid, responseChannel) | IncomingData data -> let respChannel = requestMap.[data.Id] do! respChannel.Send data.Payload return! actorLoop } let listenLoop() = async { let! data = socket.Listen() do! actor.Send (IncomingData data) return! listenLoop() }

ну чот тип того

я не помню точно как агенты в F# пишутся, но смысл думаю понятен

делаем один луп, который слушает и кидает в мейлбокс данные. Есть собсно мейлбокс который принимает только запросы клиентов и приходящие данные из сокета. Запросы клиентов регистрируются с айди запроса и ченелом ответа, приходящие данные мапятся в нужный канал ответа

всё, я тупой

я, похоже, понял

ну там надо ещё удалять из дикшнари, да

забыл про postAndReplyAsync

я не до псевдокодил все нюансы

спасибо :D

дада, он самы1й

самый прикол, что я его активно использую в других местах, а тут зацепился за TaskCompletionSource и всё

Всем привет. Есть кто-то, кто активно использует fable?

Чет мне вдруг подумалось, что мейлбоксы можно сопрячь с акторами

Используя не ask

А PostAndReplyAsync

ну началось)))

С точки зрения актора операция будет неблокирующей

Но будет торчать мутабельный стейт снаружи

с точки зрения обработки мейлбокса она должна быть неблокирующей

Ну она и будет

и да, будет с ченелами

Ты ж асинк наружу возвращаешь

Ещё вариант перед каждым изменением стейта актора вызывать внешний 'a->unit

Хотя это будет блокирующая операция

Можно асинк

Всем привет. Есть кто-то, кто активно использует fable?

С какой целью интересуешься? // Возможно придется юзать fable через пару месяцев, чтобы не дублировать тонну логики в веб-клиенте.

Можно асинк

я пока всё ещё не понимаю зачем совмещать мейлбоксы и акторов, если это по сути одно и то же)

я пока всё ещё не понимаю зачем совмещать мейлбоксы и акторов, если это по сути одно и то же)

Проблема последней мили

Или действительно создать суперактора с аском

ну так акторы тоже могут эту роль выполнять. TaskCompletionSource это и есть по смыслу ченел ответа

Как ты его вытащишь?

на клиенте, который создаёт запрос, создаём TCS, передаём куда надо с запросом. Где надо когда-то заполняется TCS

на клиенте ожидаем появления результата в нашем TCS

очевидно эта штука не сериализуется, поэтому только ин-процесс это работает)

Ну это понятно

ну я часто ченелы использую в гопачке, они там вообще для всего используются. для прокидываная NACK, для ответов, для запросов, для всего подряд короче)

А в акке как?

PipeTo норм

Стартуешь таск в актора, его результат кидаешь кому-то в мейлбокс сразу через пайпту. Это на фоне будет крутиться

PipeTo это вроде про передачу в актор

Ну да.

А тут задача обратная

Получить ответ во внешний мир

Ну тогда тебе надо работать через TCS, как аналог ченелов в TPL

Если прям без асов хочешь. Но я так не делал)

С какой целью интересуешься? // Возможно придется юзать fable через пару месяцев, чтобы не дублировать тонну логики в веб-клиенте.

Вдруг кому понадобится semantic ui на фронте, нужна мотивация и бета тестеры)

Вдруг кому понадобится semantic ui на фронте, нужна мотивация и бета тестеры)

Ты его будешь пилить в любом случае? Или ждешь некоторый объем страждующих? Не хотелось бы начать, а потом оказаться с неработающим фреймворком на руках.

Ты его будешь пилить в любом случае? Или ждешь некоторый объем страждующих? Не хотелось бы начать, а потом оказаться с неработающим фреймворком на руках.

В любом, но мотивации было бы больше и обратная связь тоже важна)

А помогите с пятым FAKE

А помогите с пятым FAKE

А что с ним?

Если раньше писалось Target "Restore" (fun _ -> DotNetCli.Restore (fun p -> {p with WorkingDir = appPath}) ) то теперь Target.create "Restore" (fun _ -> DotNet.restore и тут как-то DotNet.RestoreOptions передать? )

я что-то в сигнатурах запутался

Оу, я хз пока.

я что-то в сигнатурах запутался

так а что тебе сигнатура DotNet.restore говорит?

Хм, есть ли эксперты по fable в чате? Почему, если часто вызывать одну и ту же функцию (нет, она не рекурсивная), происходит падение с Maximum call stack size exceeded? То есть если сделать window.setInterval(loop, 20), рано или поздно loop: unit -> unit всегда начнёт выбрасывать исключения такого характера.

а в js есть tailcall рекурсия?

а в js есть tailcall рекурсия?

это вряд ли

тогда есть мнение, что не стоит делать рекурсивные вызовы в js :D

ну так соптимизировать же можно даже в жс

через вайл

Ну, setInterval — это не рекурсия же. Это вызов одной и той же функции через вайл или типа того. Рекурсивных вызовов там вообще нет.

Ну, setInterval — это не рекурсия же. Это вызов одной и той же функции через вайл или типа того. Рекурсивных вызовов там вообще нет.

да

могу доклад по теме кинуть

там когда вызываешь асинхронно методы

там всё равно будет стек вызовов и он их по очереди обрабатывает

как-то так

ща

точнее

https://www.youtube.com/watch?v=8aGhZQkoFbQ

@worldbeater

А если вкратце, то это даже с setTimeout/setInterval можно стек вызовов забить? Как тогда игори-то писать (да и на чистом JS у меня не было таких проблем никогда)

ну там есть же ещё очередь коллбеков, в которую сеттаймаут/сетинтервал пишет. мб её забиваешь за это время? (но я хз, мне просто чёт по твоему вопросу именно этот доклад вспомнился)