pfg21, мне тяжело принять такое решение. Вариант с выделением дополнительно компьютера увеличивает задержки и уменьшает пропускную способность, причём очень сильно. С другой стороны, я не вижу способа обойти ограничения сейчас. Поэтому я обратился сюда, чтобы попробовать найти способ обойтись без столько медленного решения.
Сергей Горностаев, я не могу применить такое решение, потому что не знаю, какие функции создаст пользователь. Я могу разве что описать одну общую функцию, которая принимает срез байтов и ссылку на структуру.
Василий Банников, я компилирую приложение, которое слушает TCP. Пользователь описывает функции в файле (скорее всего lua) и запускает приложение. Когда пользователь вызывает определённый endpoint с названием функции и телом запроса, приложение должно найти эту функцию, передать туда тело запроса и ссылку на структуру (или саму структуру, но сомневаюсь, что могу передавать структуры из Rust в другие языки), более того, функция может пробовать вызвать скомпилированные методы у этой структуры.
zzmaster, Вы правильно поняли. В голом React можно (через useContext, если не ошибаюсь), но так делать не принято, так как гораздо удобнее использовать готовые стейт-менеджеры (которые работают поверх useContext).
Василий Банников, Спасибо за объяснения. Честно уже год считал, что в Docker всё быстрее работает (наблюдения подтверждали эту теорию, пока не начал работать с диском).
darst, я был бы очень рад, если бы это оказалось правдой. Но этот log никогда не будет выведен (я проверил). Как я написал ранее, мы никогда не попадём здесь в это условие.
darst, это я понял. Я не могу понять, почему после прибавления size offset становится больше l. Если это допустить, то ваша теория полностью верна, однако, если я правильно понимаю свой код, в худшем случае мы получим, что offset будет равен l.
darst, я всё ещё не понял, как offset становиться больше l, если have равен size. По идеи, в худшем случае мы получим, что offset будет равен l, тогда have станет равным 0 и мы попадём в выше приведённый код.
darst, я всё ещё не понял, что вы имеете в виду. Я перечитал весь код связанный с have и не нашёл ничего плохого в том, что have может быть равным size. В этом случае мы корректно обработаем ответ, а на следующей итерации цикла have будет равен 0 и мы прочитаем ещё из соединения.
calculator212, Это я уже обнаружил. Проблема в том, что я так и не понял, при каких условия offset становится неправильным. Я проверил каждое изменение offset и не нашёл ошибку.
mayton2019, я тоже слышал про подобные различия, поэтому провёл 2 теста: в первом 2048 потоков писали по TCP, получали ответ и писали снова, во втором тесте каждый поток ждал 10 микросекунд, после чего писал по TCP, получал ответ и так N раз. В первом тесте std::thread показал себя много лучше (вплоть до 50% по скорости при меньшей нагрузке на процессор). Во втором тесте tokio и std::thread выдали одинаковые результаты, так что я предположил, что std::thread производительнее tokio, но std::thread::sleep много хуже, чем sleep из tokio. Не вижу смысла использовать tokio для повышения производительности. Но я не могу уверенно говорить, что на большем числе ядер ситуация останется такой же.
Василий Банников, имел возможность протестировать только на 6 ядрах, но на 6 ядрах обычный std::thread показал себя гораздо лучше, чем tokio. Причём я тестировал как и 6 потоков (в этом случаи логично, что std::thread быстрее), так и на 2048 потоков (и даже тут std::thread оказался гораздо быстрее). Я был бы рад узнать, почему все рекомендуют использовать tokio, вместо std.
