问题标签 [tokio]

I'm trying to get a parent process and a child process to communicate with each other using a Tokio UnixStream. Problem is that for some reason the child is unable to read whatever the parent writes to the socket (and presumably the other way around.

The function I have is similar to the following

The socket doesn't get closed, otherwise I'd get an immediate error trying to read from socks.1. If I move the read into the parent process it works as expected. The first line Reading from master gets printed, but the second line never gets called.

I cannot change the communication paradigm, since I'll be using execve to start another binary that expects to be talking to a socketpair.

Any idea what I'm doing wrong here? Is it something to do with the async/await statemachine that's generated from the async function?

我是 rust 和 tokio async 的新手，我正在尝试编译以下看似简单的代码：

但是编译器抱怨：

从我在该主题上找到的先前讨论和示例中，我了解到将对 network_config 的引用传递给 spawn-ed 闭包会导致生命周期问题，因为单独的线程可能会超过 network_config。这就是为什么我将 network_config 的克隆移动到生成的线程，但似乎仍然存在终生歧义。

是否有任何额外的提示我可以给编译器以便它正确地获得生命周期？还是我做错了整件事？

注意：NetworkConfig 类定义为：

我有一个封装结构的File结构，我希望这个结构实现AsyncRead特征，以便可以使用它来代替File代码的其他部分：

根据文档tokio::fs::File已经实现tokio::io::AsyncRead，但编译器说相反：

这里缺少什么？为什么我不能调用已经定义的方法File？

我是 Rust 的新手，我想通过实施一些小项目来学习这门语言并更好地理解。我的第一次尝试是解析从 MQTT 代理收到的 JSON 数据。tornado我很高兴在and的帮助下很容易做到这一点serde。然而，很快出现了一种我想（理想情况下）提取到特征中的模式。

其中sender通常是 atokio::sync::*::Sender并且Person会实现serde::de::DeserializeOwnedTrait。

因此，目标是实现将 atokio::stream::StreamExt<Item = Vec<u8>>和transform它转换StreamExt为关联类型Item将实现的另一个的东西DeserializOwned。

我花了很长时间才弄清楚（因为我最初想使用 Trait 或带有泛型的函数），然后我想出了

虽然这行得通，但我最初想要一个像

或实现Into实际上是相同的，我可以为StreamExt<Item = Vec<u8>>. 由于impl TraitTraits 无法返回，因此这是我认为的唯一选择。但是，我在实现这一点时遇到了几个问题。

1. 使用tokio::stream::filter_map::FilterMap<_,_>for T（这是 的返回类型filter_map()）是不可能的，因为模块filter_map是private.
2. Box<dyn StreamExt>也不可能使用，因为返回StreamExt几个Self函数。不过，我一开始不希望堆开销；）

所以我的问题是：鉴于返回类型是对象安全的和不是对象安全的，我能在这里做些什么来获得 Trait 实现的语法filter_map()糖private吗StreamExt？使用会很酷

或into()。显然我有一个可行的实现，所以这对我来说并不是一个真正的关键问题。但正如我一开始所说的，我想首先对 Rust 有更深入和更好的理解。

我注意到有tokio-serde箱子，但乍一看它只处理框架数据，所以我没有深入研究它。

transformPS：当类型推断失败时，我也遇到了我实现的自由函数的问题。例如，当将新流传递给类似的函数时

在这种情况下，它显然无法T与transfer像

但是我不想注释所有类型参数，只注释它无法推断的一个。经过反复试验，我发现我可以使用

我完全不知道。不过，我在文档中找不到这个。这是一些隐藏的功能，还是我只是未能正确 rtfm？:)

我有N输入流（队列）和N相应的连接。调度程序线程扫描传入的请求，根据某些标准对它们进行优先级排序，然后将它们发送到相应的连接上（来自队列中的请求x继续连接x）。类似的事情也发生在接收端。

在传统环境中，人们会创建与O_NONBLOCK. 如果对连接的写入将被阻塞，请将请求留在输入队列中，稍后重新访问队列，这样调度程序线程就不会在一个慢速连接上被阻塞。

等有可能tokio::net::TcpStream吗？看起来tokio::io::{TryRead, TryWrite}过去有被删除。

一种选择可能是为每个连接创建一个输出队列，每个输出队列都有一个专用任务。这只是出队并write_all().await在连接上执行。这会增加一跳，并增加复杂性。让我想知道 Tokio 是否是此应用程序的正确选择。

我只想tokio::net::TcpStream.split在结构中使用方法并将其保留为字段变量，但出现错误error[E0597]: 'stream' does not live long enough。当我试图将借来的值保存到 struct 的字段（如Struct std::path::Path. 我知道Path问题会通过 using 得到解决PathBuf，但这次我不确定。你能给我一个建议让它工作吗？

Tokio 在其上具有相同的简单 TCP 回显服务器示例：

• GitHub 主页 ( https://github.com/tokio-rs/tokio )
• API 参考主页 ( https://docs.rs/tokio/0.2.18/tokio/ )

但是，在这两页中，都没有解释实际发生的事情。这是示例，稍作修改，以便主函数不返回Result<(), Box<dyn std::error::Error>>：

阅读 Tokio 文档 ( https://tokio.rs/docs/overview/ ) 后，这是我对这个示例的心智模型。为每个新的 TCP 连接生成一个任务。每当发生读/写错误或客户端结束连接（即n == 0案例）时，任务就会结束​​。因此，如果某个时间点有 20 个连接的客户端，则将有 20 个衍生任务。然而，在底层，这并不等同于产生 20 个线程来同时处理连接的客户端。据我了解，这基本上是异步运行时试图解决的问题。到目前为止正确吗？

接下来，我的心智模型是 tokio 调度程序（例如threaded_scheduler，应用程序默认的多线程，或测试默认的单线程basic_scheduler）将在 1 对 N 线程上同时调度这些任务。（附带问题：对于threaded_scheduler，N 在应用程序的生命周期内是固定的吗？如果是，它是否等于num_cpus::get()？）。如果一个任务正在.await执行readorwrite_all操作，那么调度程序可以使用同一线程为其他 19 个任务之一执行更多工作。还是正确的？

最后，我很好奇外部代码（即.awaiting for的代码tcp_listener.accept()）本身是否是一项任务？这样，在 20 个连接的客户端示例中，实际上并不是 20 个任务，而是 21 个：一个用于侦听新连接 + 每个连接一个。所有这 21 个任务都可以在一个或多个线程上同时调度，具体取决于调度程序。在下面的示例中，我将外部代码包装在 atokio::spawn和.await句柄中。是否完全等同于上面的例子？

基于https://github.com/tokio-rs/tokio/blob/master/examples/proxy.rs上的 tokio 示例

我有一个修改版本，以便我可以处理每个连接的终止，如下所示：

这使我能够正确计时客户端的连接时间，因为客户端在收到答案后立即关闭连接，而代理服务器似乎需要（在我的情况下为 8 秒）关闭。鉴于这种代码结构，一旦我退出 client_to_server 的未来（即不等待我观察到它需要关闭的 8 秒），是否有可能终止来自 server_to_client 的下游连接？

谢谢

我是新手，并尝试理解以下错误：

尝试通过 tokio 运行多 tcp 侦听器，但得到如下错误：

类似的问题对 tokio::spawn(async move) 中的变量生命周期感到困惑

我实现了一个玩具 UDP 服务器，它通过多个并发任务尽可能快地通过一组套接字喷出数据。我天真地认为这可以通过利用 Tokio 的线程运行时来有效利用 CPU 资源：

它实践，哪些任务运行似乎是相当不确定的。通常第一个生成的任务会运行，其他 3 个任务中的任意数量都会运行（并不总是按顺序运行）。例如，输出可能类似于：

或者

但并不是我所需要的（这将显示所有 4 个 ID）。

我不禁觉得我一定在这里遗漏了一些东西。我玩过core-threads但max-threads没有任何有用的结果。

如何使这种类型的系统与 Tokio（或一般异步）可靠地工作？

虽然这是一个玩具系统，但它实际上是我想要的用例的垫脚石。