【问题标题】:libudev strange behavior v1.7.2 onwardslibudev 奇怪的行为 v1.7.2 起
【发布时间】:2011-12-07 15:39:09
【问题描述】:

我在使用 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")));
}

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

【问题讨论】:

  • 您是否检查了文档以确保 API 或其行为没有改变?否则,它可能是一个错误,应该直接发给 libudev 开发人员,而不是 SO。

标签: c++ linux udev


【解决方案1】:

是的,我看到了同样的事情。这些天似乎与 udev_monitor_receive_device 交互的唯一方法是使用 select/poll - 我有一个与您类似的循环,并在 udev_monitor_receive_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 仍然被阻塞,而不是让你跳这个舞会,那就太好了,但你去吧。

【讨论】:

    【解决方案2】:

    API reference

    监视器套接字默认设置为 NONBLOCK。 udev_monitor_get_fd() 返回的文件描述符上的 poll() 变体应该用于在新设备到达时唤醒,或者文件描述符切换到阻塞模式。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-10-29
      • 2023-01-30
      • 1970-01-01
      • 2021-06-08
      • 2015-07-20
      相关资源
      最近更新 更多