2

我正在寻找基于 libev 编写一个套接字程序。我注意到https://github.com/coolaj86/libev-examples/blob/master/src/unix-echo-server.c中所述的几个示例使用基于 init 的回调。例如，

main() {

......
ev_io_init(&client.io, client_cb, client.fd, EV_READ|EV_WRITE);
ev_io_start(EV_A_ &server.io);

}

static void client_cb (EV_P_ ev_io *w, int revents)
{
  if (revents & EV_READ)
  {
      ....
  } else if (revents & EV_WRITE) {

     ......
  }
}

我的问题来自预期的行为，例如，我在 EV_READ 中读取的所有内容都存储在链接列表中。假设我不断获得免费的数据包流来读取，我有机会进入 EV_WRITE 吗？我必须将我通过读取接收到的所有内容发送到另一个套接字。那么它会是一次 EV_READ 和第二次 EV_WRITE 吗？换句话说，EV_WRITE 什么时候会被解除阻塞？或者我是否需要阻止 EV_READ 才能调用 EV_WRITE。有人可以帮我理解这一点吗？

4

2 回答 2

2

简短地回答：如果你总是先检查一种类型的事件，然后再检查另一种类型的事件，那么else if你就有挨饿的风险。一般来说，我会检查两者，除非指定的协议无法同时激活两者。

这是一个更不确定的答案：您问题中的链接不包含代码结构，例如您的问题。客户端https://github.com/coolaj86/libev-examples/blob/master/src/unix-echo-client.c确实有类似的回调。您会注意到它在写入一次时会禁用写入事件。

// once the data is sent, stop notifications that
// data can be sent until there is actually more
// data to send
ev_io_stop(EV_A_ &send_w);
ev_io_set(&send_w, remote_fd, EV_READ);
ev_io_start(EV_A_ &send_w);

这看起来像是试图避免管道 READ 事件分支的饥饿。即使我对 libev 不是很熟悉，您链接到的 github 示例似乎也不是很健壮。例如static void stdin_cb (EV_P_ ev_io *w, int revents)不使用返回值getline()来检测EOF。此外，不会检查send()和recv()套接字操作返回值的读取或写入量（尽管在本地命名管道流上，数量很可能与请求的数量匹配）。如果稍后将其更改为基于 TCP 的连接，则检查数量至关重要。

于 2013-02-25T09:34:50.123 回答
2

我认为您应该将写回调与读回调分开：

main() {
    ev_io_init(&read.io, read_cb, client.fd, EV_READ);
    ev_io_init(&write.io, writead_cb, client.fd, EV_WRITE);
    ev_io_start(EV_A_ &read.io);
    ev_io_start(EV_A_ &write.io);
}

这是我的解决方案。

于 2016-01-21T02:17:32.710 回答