AO
А где-то можно пример последнего подхода посмотреть? Я только синхронизацию с помощью каналов видел, которая тут не подойдёт
Ну в корутинах есть мьютексы, считай просто критическую секцию сделаешь
Size: a a a
2019 October 15
AN
Просто делать канал на байты, особенно если их много- это очень дорого. Я бы сделал накопитель мутабельный и одной корутиной (если нужны именно корутины) туда писал, другой вычитывал. Собственно то, что @eld0727 сказал, только не обязательно акторы.
А
Просто делать канал на байты, особенно если их много- это очень дорого. Я бы сделал накопитель мутабельный и одной корутиной (если нужны именно корутины) туда писал, другой вычитывал. Собственно то, что @eld0727 сказал, только не обязательно акторы.
Тут прикол в том, что у меня пиксельбаттл сервер, и апдейт пикселя на поле, приходящий от клиента, весит четыре байта (байт я для упрощения задачи написал, там байтаррей). Нужно все обновлениями собирать, и раз в секунду юзерам отправлять в склеянном виде.
Не очень понятно, как работу с накопителем с кучей клиентов синхронизировать, если без каналов
Не очень понятно, как работу с накопителем с кучей клиентов синхронизировать, если без каналов
AN
Тут прикол в том, что у меня пиксельбаттл сервер, и апдейт пикселя на поле, приходящий от клиента, весит четыре байта (байт я для упрощения задачи написал, там байтаррей). Нужно все обновлениями собирать, и раз в секунду юзерам отправлять в склеянном виде.
Не очень понятно, как работу с накопителем с кучей клиентов синхронизировать, если без каналов
Не очень понятно, как работу с накопителем с кучей клиентов синхронизировать, если без каналов
Во-первых, у вас напрашивается не канал, а flow. Во вторых, переправлять по одному байту довольно дорого. Вам бы их предварительно аггрегирвоать. Если нельзя аггрегировать, но на flow аггрегатор тоже будет довольно простой.
А
Во-первых, у вас напрашивается не канал, а flow. Во вторых, переправлять по одному байту довольно дорого. Вам бы их предварительно аггрегирвоать. Если нельзя аггрегировать, но на flow аггрегатор тоже будет довольно простой.
Ого, я про них даже не знал. Выглядит прямо созданным для моей задачи. Спасибо большое
AN
Ого, я про них даже не знал. Выглядит прямо созданным для моей задачи. Спасибо большое
Ну да, они собственно для обработки потоков однородных данных и сделаны
AN
Они дешевле, чем каналы, но не бесконечно дешевые
А
Стоп. Вот у меня подключилось к пиксельбаттлу 100500 пользователей, и каждый поставил на поле пиксель, т.е отправил по 4 байта. Теперь мне их надо все склеить, и отправить результат каждому юзеру.
Судя по доке, я не смогу сделать Flow<ByteArray>, в который с каждого клиента буду emmit'ить значение. Flow можно сделать только билдером, с которым не выйдет динамически добавлять данные
Судя по доке, я не смогу сделать Flow<ByteArray>, в который с каждого клиента буду emmit'ить значение. Flow можно сделать только билдером, с которым не выйдет динамически добавлять данные
AN
Стоп. Вот у меня подключилось к пиксельбаттлу 100500 пользователей, и каждый поставил на поле пиксель, т.е отправил по 4 байта. Теперь мне их надо все склеить, и отправить результат каждому юзеру.
Судя по доке, я не смогу сделать Flow<ByteArray>, в который с каждого клиента буду emmit'ить значение. Flow можно сделать только билдером, с которым не выйдет динамически добавлять данные
Судя по доке, я не смогу сделать Flow<ByteArray>, в который с каждого клиента буду emmit'ить значение. Flow можно сделать только билдером, с которым не выйдет динамически добавлять данные
Так вы с одного конца добавляете корутиной, с другого вычитываете
AN
там есть calbackFlow
AN
Но только надо помнить, что если у вас где-то буффер переполняется, то пихающая корутина засуспендится
2019 October 16
TT
https://pastebin.com/1Q5rUSJQ Вот я реализивал описанную ниже логику, но как то все не так красиво как хотелось бы. В коде такая логика: есть функция1 которая запустит экран1, если функция2 вернет false. А когда мы вызываем эту функцию2 , она делает запрос в сеть и в зависимости от результата вернет true или false, и ассинхронно запускает deffered который ждет 300 млСек и если ответа из сети нет, прерывает запрос и возвращает false.
VB
https://pastebin.com/1Q5rUSJQ Вот я реализивал описанную ниже логику, но как то все не так красиво как хотелось бы. В коде такая логика: есть функция1 которая запустит экран1, если функция2 вернет false. А когда мы вызываем эту функцию2 , она делает запрос в сеть и в зависимости от результата вернет true или false, и ассинхронно запускает deffered который ждет 300 млСек и если ответа из сети нет, прерывает запрос и возвращает false.
suspend fun myFun(): Boolean = try {
withTimeout(300) {
val version = withContext(Dispatchers.IO) { getVersion() }
isVersionValid(version)
} catch (ex: CancellationException) {
false
}
}
как-то так может?TT
suspend fun myFun(): Boolean = try {
withTimeout(300) {
val version = withContext(Dispatchers.IO) { getVersion() }
isVersionValid(version)
} catch (ex: CancellationException) {
false
}
}
как-то так может?А как работает withTimeOut? если в течении 300 млСек функция не завершилась, вызывает исключение?
VB
А как работает withTimeOut? если в течении 300 млСек функция не завершилась, вызывает исключение?
TT
suspend fun myFun(): Boolean = try {
withTimeout(300) {
val version = withContext(Dispatchers.IO) { getVersion() }
isVersionValid(version)
} catch (ex: CancellationException) {
false
}
}
как-то так может?Вроде бы то что надо, но запрос getVersion() будет ли приостановлен? думаю нет..
VB
Если сам вызов правильно оформлен и обрабатывает отмену корутины, то будет отменен. Если вы посмотрите внутрь withTimeout то с натяжкой можно сказать что оно делает то же что делали вы в своем коде
TT
понял, спасибо, попробую такой вариант проверить
2019 October 17
AE
Там бут 2.2 подъехал https://spring.io/blog/2019/10/16/spring-boot-2-2-0
AE
Иммутабельные configuration properties теперь есть