encuesta (2) no vacía la cola de eventos

Question

Estoy usando Linux como mi plataforma de programación. Estoy usando poll(2) para saber si mi dispositivo está desencadenando un evento.

La primera llamada de poll está bien; bloquea y espera que suceda el evento. Pero en la segunda llamada a función poll, volverá; pero captura el evento. A continuación está mi código.

ret = poll(fds, 1, 2000); //2 secs timeout 

if(fds[0].revents & POLLIN && ret > 0) 
{ 
    printf("event occur\n"); 
} 

Parece que la cola/búfer no está vacía. Solo estoy asumiendo.

¿Cuál crees que es el problema?

Gracias.

Answer 1

si tiene un evento POLLIN, lo que significa "Hay datos para leer" - ¿llama a alguna función read() en su fd antes de poll() 'otra vez?

Answer 2

Obviamente, si está sondeando datos entrantes, debe consumir los datos disponibles (llamando a read()) o seguirá allí y la encuesta volverá inmediatamente. Simétricamente, ninguna operación es realmente necesaria para POLLOUT, pero normalmente desea llamar a la siguiente escritura() lo antes posible. Entonces, como regla general POLLIN -> leer, POLLOUT -> escribir.

También debe restablecer la estructura de pollfd antes de volver a llamar a la encuesta.

fds[0].fd = sck; 
fds[0].events = POLLIN; 
fds[0].revents = 0; 
ret = poll(fds, 1, 2000); //2 secs timeout 

if(fds[0].revents & POLLIN && ret > 0) 
{ 
    printf("event occur\n"); 
} 

Si no pone a cero cada vez, la basura de llamada anterior puede cambiar el comportamiento de sondeo (bueno, en realidad no, esto es sólo un problema de la portabilidad).

En el código de producción también debe verificar el valor de retorno, ya que la encuesta puede haberse interrumpido por algún motivo diferente al esperado (como una señal). Entonces, generalmente, quiere volver a llamar en lugar de leer datos que no están disponibles (como recordatorio, el valor de retorno de la encuesta es el número de eventos, 0 tiempo de espera, -1 algún error, cuyo número está en errno).

También pueden producirse errores en los descriptores de archivos proporcionados para la encuesta. No harán que la encuesta devuelva un error, pero establecerán POLLERR, POLLHUP o POLLNVAL en el campo de resolución de la estructura pollfd para ese descriptor de archivo. Si estos eventos están configurados, llamar a read devolverá un código de error que puede verificar.

Answer 3

Se considera una buena práctica comprobar POLLHUP o POLLNVAL antes de leer el descriptor de archivo. Sin embargo, creo que read() simplemente fallaría si ese fuera el caso, a menos que sondee un descriptor de archivo que se espera que bloquee durante periodos prolongados, como un módem. En ese caso, se bloqueará (según lo que haya pasado al open()).

Usted no es probable que:

• Leyendo el caso de FD en absoluto antes de la próxima poll(), o,
• de leer todos los datos disponibles.

Si ha inicializado la matriz estructura pollfd antes de llamar poll(), no debería haber ningún 'basura' para hablar de.

Aún así, es probablemente una buena idea verificar también y asegurarse de que hay algo que vale la pena molestar read() antes de llamar.

Answer 4

poll le ofrece un evento si hay datos/eventos que leer/errores/cuando puede escribir.

Si recibe un evento que dice "hay datos para leer" y no lee nada, todavía habrá "datos para leer" la próxima vez que llame al poll y obtendrá otro evento.