software - ¿Cuáles son las diferencias entre sondeo y selección?

surveymonkey (2)

Creo que this responde tu pregunta:

De Richard Stevens ([email protected]):
La diferencia básica es que select () ''s fd_set es una máscara de bits y, por lo tanto, tiene un tamaño fijo. Es posible que el kernel no limite este tamaño cuando se compila el kernel, lo que permite a la aplicación definir FD_SETSIZE a lo que quiera (como implican hoy los comentarios en el encabezado del sistema) pero requiere más trabajo. El núcleo de 4.4BSD y la función de biblioteca de Solaris tienen este límite. Pero veo que BSD / OS 2.1 ahora se ha codificado para evitar este límite, por lo que es posible, solo una pequeña cuestión de programación. :-) Alguien debería presentar un informe de error de Solaris sobre esto, y ver si alguna vez se soluciona.
Sin embargo, con poll (), el usuario debe asignar una matriz de estructuras pollfd y pasar el número de entradas en esta matriz, por lo que no hay un límite fundamental. Como señala Casper, menos sistemas tienen poll () que select, por lo que este último es más portátil. Además, con las implementaciones originales (SVR3) no se podía establecer el descriptor en -1 para decirle al kernel que ignorase una entrada en la estructura pollfd, lo que dificultaba la eliminación de las entradas de la matriz; SVR4 soluciona esto. Personalmente, siempre utilizo select () y raramente poll (), porque también transfiero mi código a entornos BSD. Alguien podría escribir una implementación de poll () que use select () para estos entornos, pero nunca he visto uno. Both select () y poll () están siendo estandarizados por POSIX 1003.1g.

Actualización de octubre de 2017:

El correo electrónico al que se hace referencia arriba es al menos tan antiguo como 2001; el comando poll() ahora (2017) es compatible con todos los sistemas operativos modernos, incluido BSD. De hecho, algunas personas creen que select() debería estar en desuso . Dejando a un lado las opiniones, los problemas de portabilidad alrededor de la poll() ya no son una preocupación en los sistemas modernos. Además, epoll() se ha desarrollado desde entonces (puede leer la página de manual ) y sigue aumentando su popularidad.

Para el desarrollo moderno, probablemente no desee usar select() , aunque no hay nada explícitamente incorrecto con él. poll() , y su evolución más moderna epoll() , proporciona las mismas características (y más) que select() sin sufrir las limitaciones que allí se presentan.

Me refiero a las llamadas a la API C del sistema de poll y select POSIX estándar.

La llamada a select() hace que cree tres máscaras de bits para marcar qué sockets y descriptores de archivos desea ver para lectura, escritura y errores, y luego el sistema operativo marca cuáles de hecho han tenido algún tipo de actividad; poll() hace que crees una lista de ID de descriptores, y el sistema operativo marca cada uno de ellos con el tipo de evento que ocurrió.

El método select() es bastante torpe e ineficiente.

Normalmente hay más de mil posibles descriptores de archivos disponibles para un proceso. Si un proceso de larga ejecución tiene pocos descriptores abiertos, pero al menos uno de ellos tiene un número alto, entonces la máscara de bits pasada a select() debe ser lo suficientemente grande para acomodar el descriptor más alto, por lo que rangos enteros de cientos de bits no se configurará que el sistema operativo tiene que repetir en cada llamada select() solo para descubrir que están desarmados.
Una vez que select() regresa, la persona que llama debe recorrer las tres máscaras de bits para determinar qué eventos tuvieron lugar. En muchas aplicaciones típicas, solo uno o dos descriptores de archivos obtendrán tráfico nuevo en cualquier momento dado, sin embargo, las tres máscaras de bits deben leerse hasta el final para descubrir qué descriptores son.
Debido a que el sistema operativo lo señala sobre la actividad reescribiendo las máscaras de bits, se arruinan y ya no se marcan con la lista de descriptores de archivo que desea escuchar. O bien tienes que reconstruir toda la máscara de bits de otra lista que guardas en la memoria, o tienes que mantener una copia duplicada de cada máscara de bits y memcpy() el bloque de datos encima de las máscaras de bits arruinadas después de cada llamada select() .

Entonces, el método poll() funciona mucho mejor porque puede seguir reutilizando la misma estructura de datos.

De hecho, poll() ha inspirado otro mecanismo en los núcleos Linux modernos: epoll() que mejora aún más el mecanismo para permitir otro salto en la escalabilidad, ya que los servidores de hoy a menudo quieren manejar decenas de miles de conexiones a la vez. Esta es una buena introducción al esfuerzo:

http://scotdoyle.com/python-epoll-howto.html

Si bien este enlace tiene algunos buenos gráficos que muestran los beneficios de epoll() (notará que select() es considerado por este punto tan ineficiente y pasado de moda que ni siquiera consigue una línea en estos gráficos):

http://lse.sourceforge.net/epoll/index.html

Actualización: Aquí hay otra pregunta sobre desbordamiento de pila, cuya respuesta brinda aún más detalles sobre las diferencias:

Advertencias de select / poll vs. reactores epoll en Twisted