f
Size: a a a
2021 November 01
f
Но poll_unparked объявлено на 666й строке...
D
ваще конкретно этот код не оч, т.к.
channel.send(msg) вполне себе может вернуть Pending (например, потому что из другого потока уже забили очередь), а ты, получается, просто игнорируешь невыполнениеf
ой, там должно быть start_send
f
Видимо
mpsc::Sender не гарантирует наличие слота после poll_readyD
дык бери токио и горя не знай :))
V
или flume :)
D
или flume)
f
Ну... да 🙂 Но мне надо доделать огроменный рефакторинг, отладить стабильность, и потом уже смотреть на другие либы
D
в токио-то прикольно то, что этот пермит можно явно использовать, типа получил пермит — а потом гарантированно отправил, на парясь о том, что там в других потоках кто-то параллельно может забить очередь канала
f
Но такое поведение меня более чем устраивает
f
Угу, это весьма красиво
V
Тут согласен, удобно
Можно даже самому пермиты резервить и сохранять куда-нибудь
Можно даже самому пермиты резервить и сохранять куда-нибудь
f
Отправлять голубями 🙂
D
:))
NN
А может кто подкинуть ссылку на чтиво о том как спроектировать свою библиотеку так, чтобы ей можно было пользоваться независимо от выбранного рантайма. ну т.е. не вязаться на конкретику tokio/async-std /wtfelse, а типа best practices.
2021 November 02
D
Через фичи обычно делают
D
По поводу best practices -- не встречал, но может кто всё-таки видел что-то на тему?
2021 November 05
w
А у меня другой вопрос: как мне отвязаться от конкретной зависимости
use tokio_stream::StreamExt; в следующем коде?let mut nics = heim::net::nic().filter(|nic_res| match nic_res {
Ok(n) => n.is_up() && !n.is_loopback(),
_ => false
});
причем heim::net::nic() возвращает Stream
Когда я прописываю use futures::stream::StreamExt;
то возникает ошибкаlet mut nics = heim::net::nic().filter(|nic_res| match nic_res {
| ^^^^^^ `bool` is not a future
(указывает на filter)ph
У тебя вопрос почему у tokio StreamExt и futures StreamExt разные сигнатуры или как добавить async внутрь filter?