libudev奇怪的行爲v1.7.2以上

我面臨着libudev的某個問題。我寫了一個監聽線程，不斷監聽通過USB連接的設備。我在連續的while循環開始時使用了libudev API udev_monitor_receive_device，因爲它是一個阻塞調用。這個源代碼在libudev v1.6.3中可以正常工作，但是當升級到v1.7.2時，對udev_monitor_receive_device的調用不再被阻止，並且while循環持續運行，並且api始終返回NULL。下面是代碼，這將有助於你理解我的代碼libudev使用的部分..libudev奇怪的行爲v1.7.2以上

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"))); 
}

這個問題一直纏着我很長一段時間。任何幫助，將不勝感激。

來源

2011-12-07 Manish Narang

您是否檢查了文檔，以便API或其行爲沒有改變？否則，它可能是一個錯誤，應該直接指向libudev開發人員，而不是SO。 –

是的，我看到同樣的事情。似乎與udev_monitor_receive_device這些天交互的唯一方法是選擇/民意調查 - 我有一個類似的循環給你，加上幾行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仍然受阻直到有數據準備好，而不是讓你做這個舞蹈，但你去了。

來源

2012-06-25 13:05:50 sqweek

見API reference：

顯示器插口是默認設置爲NONBLOCK。當新設備到達時，應使用udev_monitor_get_fd（）返回的文件描述符上的poll（）變體，或者將文件描述符切換到阻塞模式。

來源

2014-01-08 19:27:55 Lars

libudev奇怪的行爲v1.7.2以上

回答

相關問題