gpt4 book ai didi

c++ - libudev 奇怪的行为 v1.7.2 起

转载 作者:太空宇宙 更新时间:2023-11-04 11:35:19 29 4
gpt4 key购买 nike

我正面临 libudev 的某个问题。我写了一个监听器线程,不断监听通过 usb 连接的设备。我在连续 while 循环开始时使用了 libudev API udev_monitor_receive_device,因为它是一个阻塞调用。源代码适用于 libudev v1.6.3,但是当升级到 v1.7.2 时,对 udev_monitor_receive_device 的调用不再阻塞并且 while 循环持续运行并且 api 不断返回 NULL。下面是一部分代码,可以帮助您理解我的代码中 libudev 的用法。

struct udev *udevObject ;
struct udev_device *mDev;
struct udev_enumerate *enumerate;
struct udev_monitor *mUdevMonitorObject;

udevObject = udev_new();
if(NULL == udevObject){
LOGERR((TEXT("Listener thread :: Error initialising Udev Library\r\n")));
return false;
}
mUdevMonitorObject = udev_monitor_new_from_netlink(udevObject, "udev");
udev_monitor_enable_receiving(mUdevMonitorObject);
// enumerate = udev_enumerate_new(udevObject);
// udev_enumerate_scan_devices(enumerate);


while(1)
{
// This loop keeps running continuously on libudev v1.7.3, but the call blocks for v1.6.3
mDev = udev_monitor_receive_device(mUdevMonitorObject);
LOGINFO((TEXT("Listener thread:: Processing UDEV trigger\r\n")));
}

这个问题困扰了我很久。任何帮助将不胜感激。

最佳答案

是的,我看到了同样的事情。这些天与 udev_monitor_receive_device 交互的唯一方法似乎是使用 select/poll - 我有一个类似的循环,在 udev_monitor_recieve_device 之前添加这些行使一切都变得合理:

int fd = udev_monitor_get_fd(mUdevMonitorObject);
fd_set fdset;
FD_ZERO(&fdset);
FD_SET(fd, &fdset);
if(select(fd+1, &fdset, NULL, NULL, NULL) < 0) {
/* error in select */
continue;
}

如果 receive_device 在数据准备就绪之前仍然处于阻塞状态而不是让你跳这个舞就好了,但是你走了。

关于c++ - libudev 奇怪的行为 v1.7.2 起,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8418020/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com