Основной канал. Конференция в Москве https://rustrush.ru/index-ru ! Простые вопросы сюда: https://gitter.im/ruRust/easy . Поддержите сообщество: https://www.patreon.com/mkpankov . Правила: https://rustycrate.ru/rules.html . Помощь в исправлении ошибок, отладке, технические вопросы. Оффтопик - https://gitter.im/ruRust/offtopic . Сайт - http://rustycrate.ru/ . Форум - http://forum.rustycrate.ru/
доказательство того, что данные копируются - это разные адреса указателей https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=99e1edd47c6886a8f35807aa7d246323
Там на самом деле сам по себе вызов может и не копирует, но вызвать его можно только внутри
unsafe{ } и происходит move. Поэтому как ни крути - а копирование есть. А раз оно есть, то теряется смысл использования неинициализированных буферов
https://doc.rust-lang.org/beta/std/mem/union.MaybeUninit.html#safety к слову обрати внимание на safety
вообще по сорцам оно не должно особо ничего копировать
я кстати это спрашивал когда-то https://users.rust-lang.org/t/how-to-avoid-copying-data-with-maybeuninit/30513/2
если аккуратно то можно через get_mut доставать данные и не забыть дропнуть в конце
А как им было сделать иначе? Так мувы в расте работают
работа со стеком, вызовы функции - это всё что аффектится
и это супер базовые вещи
они даже в документации написали что есть копирование: https://doc.rust-lang.org/std/mem/union.MaybeUninit.html#correct-usage-of-this-method-1`
// However, using `.assume_init()` may trigger a `memcpy` of the 2048 bytes.
Вобщем, нужно ждать, когда они стабилизируют
feature(maybe_uninit_ref)
впрочем, на больших объектах таких методов не делают
И там речь идет про оптимизатор, к тому же. Если сделать N=2000 то оптимизатор делает одинаковый код https://rust.godbolt.org/z/rz9E7E но только при уровне оптимизации
-C opt-level=2 и выше
Это немножко не то.
и если да, то это ж получается что у нас будет UB в таком коде https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e0172ad3983ce2d14069513da32dd0fd
Похоже, что да.
Ну или я не так понимаю, где ты UB видел...
но похоже что нет, в расте даже тест есть https://github.com/rust-lang/rust/blob/master/src/test/ui/structs-enums/struct-order-of-eval-2.rs
Привет, подскажите пожалуйста, как лучше сделать.
У меня HTTP сервер на actix-web (actix-rt runtime), к нему дописываю scheduler, типа cron, работает в отдельном потоке, но там тоже
используются асинхронные функции, то есть мне туда нужно прокинуть tokio::Runtime.
Пока вижу два варианта: просто в новом потоке заново создать новый tokio::Runtime, или же прокинуть в новый поток handler из корневого рантайма. Как более правильно и производительно?
У меня HTTP сервер на actix-web (actix-rt runtime), к нему дописываю scheduler, типа cron, работает в отдельном потоке, но там тоже
используются асинхронные функции, то есть мне туда нужно прокинуть tokio::Runtime.
Пока вижу два варианта: просто в новом потоке заново создать новый tokio::Runtime, или же прокинуть в новый поток handler из корневого рантайма. Как более правильно и производительно?
@koshkin-na
Если через хендл запускать на рантайме первого потока, ты запускаться таски будут именно в первом потоке.
Чтобы что-то асинхронное запустить во втором потоке, там нужно будет поднять рантайм - или с помощью tokio, или с помощью самого актикса. Без собственного рантайма ничего асинхронного там не будет.
Ещё маленькая деталь: актикс-веб запускает не один поток для обработки веб-запросов и может их перезапускать в случае падений (и такое случается).
Поэтому будет логичным, если у крона будет свой отдельный независимый поток, а где будет запускаться то, что будет напланировано с его помощью - это уже отдельный вопрос.
Что будет производительнее - зависит от нагрузки. Если задач мало и они "маленькие" - всё будет очень хорошо работать в одном потоке и не сильно будет мешать крону. Если задачи "не вмещаются" в поток или есть "тяжёлые" вычислительные или блокирующие задачи, занимающие много времени на выполнение без переключения, - нужно думать про вынесение мешающих задач в отдельный поток или о распределении их на пул потоков - опять же, по ситуации.
Если через хендл запускать на рантайме первого потока, ты запускаться таски будут именно в первом потоке.
Чтобы что-то асинхронное запустить во втором потоке, там нужно будет поднять рантайм - или с помощью tokio, или с помощью самого актикса. Без собственного рантайма ничего асинхронного там не будет.
Ещё маленькая деталь: актикс-веб запускает не один поток для обработки веб-запросов и может их перезапускать в случае падений (и такое случается).
Поэтому будет логичным, если у крона будет свой отдельный независимый поток, а где будет запускаться то, что будет напланировано с его помощью - это уже отдельный вопрос.
Что будет производительнее - зависит от нагрузки. Если задач мало и они "маленькие" - всё будет очень хорошо работать в одном потоке и не сильно будет мешать крону. Если задачи "не вмещаются" в поток или есть "тяжёлые" вычислительные или блокирующие задачи, занимающие много времени на выполнение без переключения, - нужно думать про вынесение мешающих задач в отдельный поток или о распределении их на пул потоков - опять же, по ситуации.
cap'n'proto есть, а что еще?
