问题标签 [libevent]

谁能展示（通过代码）或向我解释我如何在 ac 程序中一起使用 libevent 和 curl？我正在尝试编写一个高性能的非阻塞数据监视器，它需要将数据上传到 CouchDB 实例。我对 libevent 和 curl 都很熟悉，但是将 curl_multi 与 libevent 合并让我不知何故感到困惑。我不明白官方libcurl 示例的程序流程- 谁能指出或提供一个更简单的示例？

首先，我想我需要说我还在学习 C++，如果这非常明显/简单，我深表歉意。

我正在尝试在我的 C++ 程序中使用 libevent 库（通过尝试查看示例文件夹中的代码并测试了一些）来使用 http 流。我想知道是否有人可以为我提供一个示例，说明我将如何连接到 URL，例如 live.domain.com，发送适当的标头，读取返回的数据并通过同一连接发送回数据......我不确定 libevent 是否有任何阻塞连接，但为了明确起见，我正在寻找非阻塞样本。

我为什么要这样做？

我正在使用一个 API，它要求你打开一个连接，除非出现错误，否则它会保持活动状态。它会定期向连接的客户端发送状态文本，直到它通过同一连接接收到带有 ID 的字符串。此时它开始发回有关给定 ID 的数据...我不完全确定在初始请求严格遵守之后通过同一连接发回数据，但这正是服务器所期望的，所以它会工作...如果我知道怎么做

提前致谢

我目前正在使用 libevent 编写一个多线程应用程序。

一些事件是由 IO 触发的，但我需要几个由代码本身跨线程触发的事件，使用 event_active()。

我试图编写一个简单的程序来显示我的问题所在：

该事件是使用 event_new() 创建的，并且 fd 设置为 -1。

调用 event_add() 时，如果使用了超时结构，则该事件稍后会由 event_base_dispatch 正确处理。

如果改用 event_add(ev, NULL)，它返回 0（显然成功），但 event_base_dispatch() 返回 1（这意味着没有事件没有正确注册。）

可以使用以下代码并交换 event_add 行来测试此行为：

编译：g++ sample.cc -levent

问题是，我不需要超时，也不想使用 n 年超时作为解决方法。因此，如果这不是使用用户触发事件的正确方法，我想知道它是如何完成的。

是否可以使用 libevent 来监视文件删除/更新？

假设 /var/log/file.1 被删除，我想在我的程序中报告它。这可能吗？如果是，如何？

我的操作系统是 Linux，我想创建一个在某些操作系统操作期间触发消息的恶​​魔。

我在哪里可以找到更多信息？

我正在尝试将一个成员函数传递给应该被视为回调的libevent 。

我可以成功地在 A 类中创建一个指向eventcb的方法指针，并在 A 的实例上调用它（第 20 行）。

此外，在第 22 行传递一个全局函数（就像在 C 中所做的那样）也可以正常工作。

但是，在第 23 行，我尝试将我的方法指针传递给libevent，当我编译它时，我收到以下错误（使用clang编译器）

我究竟做错了什么？

考虑libeventvs. libev_ 该libev库是否在 Windows 上具有对 IOCP 的本机支持？

如果我们主要想要一个epoll基于文件描述符的循环，那么libevent提供的其他功能（不感兴趣http或不感兴趣dns）？

我知道这是一个相当大的项目，但对我来说编写epoll包装 API 看起来很简单。

是否libevent处理缓冲文件 I/O？我知道它可以很好地处理套接字，但它是否也涉及普通文件或者它“只是”一个epoll/...包装器？

为什么这不起作用，文件test.c：

然后： gcc -o test.o -c test.c运行正常，但是

链接： g++ -o test -levent test.o生产

所以它不能链接为C++. 如何解决这个问题？我需要将其链接为C++并编译为C.

我正计划编写一个“彗星”服务器，用于向客户“流式传输”数据。过去我增强了一个以利用多核 CPU，但现在我从头开始。我打算使用 epoll/kqueue 或 libevent 为服务器供电。

我一直在权衡的问题之一是使用什么服务器设计？我有几个可用的选项，因为我计划使用多进程模型来利用所有 CPU 内核。

1. 预分叉的多进程 - 每个进程都有自己的接受
2. 带有主进程的预分叉多进程 - 主进程接受然后使用描述符传递将接受的套接字传递给进程
3. 具有不同端口的预分叉多进程 - 每个进程侦听同一系统上的不同端口。负载均衡器根据来自各个守护进程的一些负载反馈来决定哪个进程获得下一个连接

设计#2 是最复杂的。设计#3 很简单，但无论设计如何，我都需要额外的硬件，因为我将在多台机器上运行它，并且无论如何都需要负载均衡器。设计#1 有雷群问题，但我想雷群对于 8 个进程来说并不是什么大问题，但是当客户端不断连接和断开连接时它就变得很重要（这应该很少见，因为这是一个彗星服务器）。

正如我所看到的，#2 很复杂，并且需要 2 个额外的系统调用，因为描述符在每个接受的主从进程之间传递。将这种开销与雷鸣般的羊群问题相对会更好吗？如果我有 8 个进程唤醒并执行接受，我是否可能会看到 8 个接受调用，以防我使用设计#1？

我的设计选择的优缺点是什么？你会推荐什么？