Minoru
Akon32: upgrade().unwrap() создал тебе временную переменную типа Rc<Mutex<HashMap<TaskId, TaskResultReceiver>>>, которая живёт до ближайшей точки с запятой (если её никуда не сохранить). Дальше на этой переменной вызывается lock().await, которые возвращают тебе MutexGuard<HashMap<TaskId, TaskResultReceiver>>, лайфтайм которого должен быть строго меньше лайфтайма Rc (иначе получится, что ты держишь мьютекс, находящийся внутри помершего Rc)

Akon32
там Arc, точнее.

Minoru
ну, не суть

Minoru
теперь понятно, почему дополнительный let фиксит проблему?

Akon32
а если Arc в переменную сохранять, её лайфтайм до конца блока?

Akon32
идея ясна, но, когда я днём то же самое пытался сделать, не получалось.

Minoru
обычно да, но ты можешь ещё до окончания блока дропнуть явно (std::mem::drop) или переместить куда-то

Akon32
может, потому, что ниже я drop(arc_ws) делал..

Akon32
вот если drop - то ругается, типа переменная заимствована в await.

Minoru
Akon32: скорее всего, ты делал не совсем то же самое. Тут всякие тонкости могут случаться, я не могу предсказать

Minoru
ну дык

Minoru
ты создал Arc, залочил внутри него мьютекс

Minoru
и пытаешься дропнуть Arc

Minoru
что, по-твоему, при этом должно произойти с залоченным мьютексом?

Akon32
хм!

Akon32
надо сначала дропать мьютекс?

Minoru
чтобы такого избежать, нужно сначала дропнуть MutexGuard, разлочив мьютекс, а потом уже дропать Arc

Minoru
да

Akon32
*MutexGuard

Minoru
ну, или помещать всё это в блоки, чтобы было очевидно, что где куда