- kkolyan
- Постоялец
kkolyan
> Дак и в расте не нужны. Сделай враппер вокруг UnsafeCell которые чекает что доступ из правильного треда. Есть крейт, но я забыл название. Могу глянуть а репках, если интересно
На самом деле я Rust только изучаю, поэтому хочется обходиться по максимуму только std либой, где это возможно. Понятно, что есть воркэраунды для много чего, но пока я лучше по простому.
KolyaL
Дело хорошее)
Там мало кода, можешь осознать и сделать аналогично
https://github.com/dtolnay/threadbound/blob/master/src/lib.rs
KolyaL
> Потому кто-то другой начнет юзать это (не зная, что это) в другом потоке и охренеет.
контейнер с понятным именем и апи. при неверном использовании выстрелит быстро и понятно.
А что, лучше чтобы оно сегфолтило? Или перф подъедало, или колом вставало рандомно?
> Это же можно не явно использовать.
Как, например?
kkolyan
> Как, например?
Например, есть какой-то объект А, он содержит внутри залоченный объект В.
Мы же можем предать в другой поток объект А? Если что-то у него вызвать, что использует В, то случится неприятность. Это если я правильно понимаю
KolyaL
> Мы же можем предать в другой поток объект А?
Попробуй и посмотри что получится. Когда ты лочишь объект, то ты получаешь взамен MutexGuard, который владеет объектом и снимает лок в момент своего уничтожения. Соответственно пока ты не снимешь владение, то объект ты никуда не передашь, а можешь передать только немутабельную ссылку на него, по которой никто ничего плохого с ним сделать не сможет.
Zefick
> Попробуй и посмотри что получится. Когда ты лочишь объект, то ты получаешь взамен MutexGuard, который владеет объектом и снимает лок в момент своего уничтожения. Соответственно пока ты не снимешь владение, то объект ты никуда не передашь, а можешь передать только немутабельную ссылку на него, по которой никто ничего плохого с ним сделать не сможет.
Ну и по немутабельной ссылке тоже можно вызвать ф-ию, которая использует залоченный на другой поток объект В.
KolyaL
> Ну и по немутабельной ссылке тоже можно вызвать ф-ию, которая использует залоченный на другой поток объект В.
Можно и что? В чём проблема? Ты не можешь сделать ничего с объектом по немутабельной ссылке. Более того: если у тебя есть немутабельная ссылка, то значит в помент работы с ней никто другой не может менять этот объект потому что запрещено одновременно с иммутабельными ссылками иметь мутабельные. Поэтому передавать их полностью безопасно даже между потоками. Естественно всё можно при желании обойти, но если ты не будешь делать этого специально, то ничего страшного не будет.
Zefick
> Можно и что? В чём проблема?
Ну мы https://docs.rs/threadbound/latest/threadbound/ вот это обсуждаем. Что подобный залоченный на какой-то поток объект, может быть вызван неявно из другого потока.
KolyaL
Ну да, с великой силой приходит и великая ответственность)
Но это лучше, чем если такой объект кто-то поиспользует в неправильном потоке и закорраптит его, или если будет происходить блокировка, чреватая взаимной.
PS: в этом крейте есть кстати серьезное ограничение ограничивающее последний кейс о котором ты говоришь: Send только для "T: Copy". но для глобал статика Send не нужен)
PPS: режет глаз: привязанный, а не залоченный. залоченность - это про блокировки.
Чувак слишком быстро говорит, но если я его правильно понял, недавние проблемы с CloudFlare, повлиявшие на многие сайты, работающие за ним (в частности, я столкнулся с этим на паре русскоязычных форумов), были вызваны криворукостью при использовании Rust, на котором (если ему автору ролика) написан бакэнд CloudFlare.
Конкретнее, кто-то в кишках оставил unwrap, который начал обкакиваться паникой, когда некий параметр "количество фич" вышел за какой-то там захардкоженный предел.
И коммунити сейчас подгорает, что unwrap (и попутно expect) надо было бы назвать .or_panic() или как-то так, чтоб в глаза бросалось, что в данном месте может обкакаться.
Имхо, немалая вина тут в разработчиках документации - там чуть ли не в каждом втором примере без тени смущения используют unwrap.
Dmitry_Milk
вероятно, было бы полезно иметь в языке скоуп "can panic" по аналогии с unsafe. чтобы точно знать какой метод может паниковать а какой нет и тем самым легко форсить в серверном продакшн коде отсутствие паник (и не форсить в тулзах и тестах).
Вот тут текстом: https://hackaday.com/2025/11/20/how-one-uncaught-rust-exception-t… t-cloudflare/
Ну тупо просохатили как я понял проверку на ошибку и это просто то что обязательно надо делать перед unwrap и всего лишь.
Неважно в каком языке такую ошибку совершать - тупо код не обрабатывает ошибку и unwrap не вызвал бы тогда проблем.
P.S.
Не думал что у меня форматирование отступов может вызвать проблемы затрудняющие понимание что вообще написано, но тут они этого добились.
=A=L=X=
в каком смысле unwrap бы не вызвал проблем? разве остался бы в коде unwrap в случае обработки ошибки?
=A=L=X=
а вообще, судя по довольно тупым комментам - это предположительно вайбкод, если так, то разрабы тупо поспешили/поленились и не смотрели что делают.
=A=L=X=
> тупо код не обрабатывает ошибку и unwrap не вызвал бы тогда проблем.
Вообще не должно быть unwrap/expect и прочих паникующих вещей в коде работающих фоном сервисов.
Я до сих пор не понимаю, почему индексацию оставили паникующей, а не сделали по умолчанию возвращающей Option<&T>/Option<&mut T>.