AN
Ну кароче можно
Size: a a a
2020 September 06
AN
Только надо процедурные макросы писать.
P
хз, как-то оно не ок выглядит всё равно
AN
Кстати в расте try не предполагает панику обычно, а наоборот
AN
Те идиоматически такое должно назваться unwrap_locks!
P
ну, или так, я не настаиваю, это просто пример как бы это выглядело
EG
Дешёвый вариант
trait LockUnwrapShortcut {
type Output;
fn lu(&self) -> Self::Output;
}
impl LockUnwrapShortcut for Mutex<T> {
type Output = MutexGuard<T>;
fn lu(&self) -> Self::Output { self.lock().unwrap() }
}АД
Чат, кто-нибудь знает крейт, умеющих делать zip-архивы с неблокирующими методами, а futures::Stream?
AN
ну, или так, я не настаиваю, это просто пример как бы это выглядело
Я не думаю что оно того стоит. Только как упражнение с макросами.
EG
Чат, кто-нибудь знает крейт, умеющих делать zip-архивы с неблокирующими методами, а futures::Stream?
А как? У тебя ж зипование происходит на процессоре, зачем тебе тут асинхронность?
EG
Или у тебя на входе стрим?
А
Привет
AV
Переслано от Alexander Zaitsev
Есть структура, у неё методы, которые что-то делают с состоянием структуры (читают, изменяют).
Сами методы не thread safe, поэтому для использования из разных потоков используется
Понятно, что такое можно реализовать простым враппером, который дублирует все методы и на каждом методе
Внимание вопрос: а можно ли как-нибудь этот враппер не писать самому руками, а заставить его сгенерироваться? Также может быть это вообще делается как-то нормально и без врапперов левых
Сами методы не thread safe, поэтому для использования из разных потоков используется
Arc + Mutex. Но не нравится, что приходится постоянно писать var.lock().unwrap().do_something(), хочу var.do_something(), а оно внутри пусть уже мьютексы лочит и выполняет остальное.Понятно, что такое можно реализовать простым враппером, который дублирует все методы и на каждом методе
lock вызывает сам.Внимание вопрос: а можно ли как-нибудь этот враппер не писать самому руками, а заставить его сгенерироваться? Также может быть это вообще делается как-то нормально и без врапперов левых
Только если прок-макросом, и указывать список методов с сигнатурами
А автоматически не получится, нужна рефлексия
А автоматически не получится, нужна рефлексия
B
не понимаю, почему куча чем-то важнее стека, это просто перераспределение ресурсов без усложнения кода
Кучу можно освободить, а стек только расти может, а потом может уйти в файл подкачки
(Расти в поане ленивого выделения страниц ядром)
(Расти в поане ленивого выделения страниц ядром)
P
Кучу можно освободить, а стек только расти может, а потом может уйти в файл подкачки
(Расти в поане ленивого выделения страниц ядром)
(Расти в поане ленивого выделения страниц ядром)
что значит "освободить"? а данные оттуда куда денутся? а стек не пейджится?
P
оно ж точно так же на виртуальной памяти работает
B
что значит "освободить"? а данные оттуда куда денутся? а стек не пейджится?
Алгоритм которому надо 256мб стэка отработал, и вернулся по стеку в самое начало, а память занята. Если повезет, то засвопится
P
Алгоритм которому надо 256мб стэка отработал, и вернулся по стеку в самое начало, а память занята. Если повезет, то засвопится
то же самое и с кучей, ты место просто заранее аллоцировал и не переаллоцируешь больше, не можешь упасть потому что мало памяти и аллок не сработал. Тоесть, это то же самое, что выделить себе память заранее, сколько надо, и больше не крутить её туда-сюда. Алгоритм вернулся в начало и может на следующем шаге опять все 256 мегабайт прокрутить, ему не надо для этого снова их аллоцировать.
DF
Глибц дёргает брк с отрицательным значением если на кончике кучи достаточно килобайт . В чем-то Богдан прав. То есть не все попадает в фрилист навечно
DF
Но так же и стек можно отмапить например nptl это делает при выходе потока