選擇（2）超時的奇怪行爲

檢查pjsip的套接字選擇的性能，我發現一個非常奇怪的行爲與超時。在socket_select.c的源代碼如下：選擇（2）超時的奇怪行爲

struct timeval os_timeout, *p_os_timeout; 

PJ_CHECK_STACK(); 

PJ_ASSERT_RETURN(sizeof(pj_fd_set_t)-sizeof(pj_sock_t) >= sizeof(fd_set), 
       PJ_EBUG); 

if (timeout) { 
os_timeout.tv_sec = timeout->sec; 
os_timeout.tv_usec = timeout->msec * 1000; 
p_os_timeout = &os_timeout; 
} else { 
p_os_timeout = NULL; 
} 

return select(n, PART_FDSET_OR_NULL(readfds), PART_FDSET_OR_NULL(writefds), 
     PART_FDSET_OR_NULL(exceptfds), p_os_timeout);

我檢查，並通過選擇函數的所有參數都正確和超時值始終重新初始化後選擇正確的值。如果還設置爲最大使用的文件描述符。

的問題是，有時，超時被適當地燒製，並用0退出但是，有時，它就會被阻塞的一個隨機時間（從一些毫秒至幾分鐘），也返回0。

我目前我正在檢查每個fd_set中的內容，以防萬一，但是如果有人知道哪些內容可能出錯，我將非常感激。

來源

2012-10-23 jcm

這個問題很可能不在socket_select.c中。你在哪裏打電話給選擇？您是否使用多個線程並從另一個線程調用select？你可以發佈你的代碼或提供鏈接？

來源

2012-10-25 02:03:23

源代碼只是pjsip的1.x分支版本4109.這是從ioqueue_select.c（在pj_ioqueue_poll中）調用的pj_sock_select的代碼。另一方面，我創建了一個基本的選擇測試應用程序，並且我看到，當有套接字活動時，我也會在超時（不是很大，大約7或8毫秒）中出現一些延遲。所以，我認爲，Android的選擇實現應該有一個問題。 – jcm

我記得有一個使用Android NDK構建PJSIP 1.8.10的補丁。 http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2011-October/013409.html。查看您的PJSIP版本是否還需要補丁您是否使用最新版本的Android-NDK？如果您使用PJSIP 2.x，你會發現有什麼區別嗎？ –

感謝您的鏈接，但我已經在使用此補丁以及其他一些改進。我沒有使用最新的NDK，但是7，我會嘗試PJSIP 2.0，但是套接字的源代碼與1.8版本相同。另一方面，我檢查了Android的通用內核源代碼，我認爲，如果文件操作的輪詢回調被阻止，問題可能出現在select的實際實現中。我試圖解決這個問題，但現在沒有運氣:-( – jcm

選擇（2）超時的奇怪行爲

回答

相關問題