Lo que hace esto es introducir un nuevo parámetro de configuración para NAPI. NAPI, que tendrá más de dos decadas ya, es la "nueva" API para dispositivos de red que permite recibir paquetes cuando el dispositivo los recibe, reaccionando a una interrupción de red, pero también entrar en un bucle preguntándole al dispositivo si hay más paquetes disponibles. Preguntar (polling) es mejor si hay paquetes disponibles, pero un despilfarro si no los hay. En esencia, decidir entre una cosa y otra es un problema de predecir el futuro (esto implica que no hay soluciones perfectas, sólo heurísticas mejores y peores).
Esto ya es controlable con algunos parámetros. pero el nuevo parámetro permite a una aplicación configurar un temporizador que le permite permanecer en modo polling mientras tiene trabajo que hacer, el valor a configurar dependerá de lo que supuestamente tarde la aplicación en procesar los paquetes devueltos por una llamada a epoll. De este modo, mientras la aplicación esta procesando los paquetes, no revierte al modo interrupción.
#29 No debería ser tan impensable, así como dice otro comentario, el problema es saber qué problema ocurre, dónde está, y que solución fácil aplicar. Es como el típico caso de profesional que cobra por apretar un tornillo... ya, pero tienes que saber cuál es, a posteriori es obvio, cuando no sabes que pasa estas jodido.
Además, es un sistema genérico, que se usa en aplicaciones muy especializadas, y que no siempre son previsibles esos problemas.
#29 No es para nada sencillo. Lo complejo del tema es saber dónde se produce el cuello de botella y que la solución sea retrocompatible, que es lo difícil muchas veces.
A su vez, para poder leer ese código y saber qué hace, hay que saber bastante del tema. Cosa que actualmente es muy difícil que ocurra debido a la ultraespecialización.
Una PCR te puede decir si entre dos puntos de una molécula de ADN hay continuidad, porque amplifica un trozo bidireccionalmente (aportando uno los puntos extremos), y si da un producto lineal del tamaño esperado es señal de que existe esa conexión física. Una RT-PCR simplemente incluye un paso para pasar de ARN a ADN antes de hacer esa amplificación.
La cosa es que al secuenciar se producen lecturas cortas de muchos fragmentos del material genético. Un ensamblador será el programa que las organizará e intentará reconstruir a partir de todos esos trocitos los fragmentos originales, por ejemplo un genoma. Lo hace, en principio, gracias a lecturas que se solapen. Hay varios problemas técnicos que pueden darse ahí, no obstante. Cuando hay repeticiones o secuencias palindrómicas se pueden mezclar las cosas, reconstruirse bucles que no existen, etc., es todo un mundo. Cuanto más largas sean las lecturas de secuenciación (eso depende de la tecnología que se use), pues mejor para hacer esa reconstrucción, porque despistan menos las secuencias repetitivas cortas.
Entonces, con una PCR podrías salir de dudas sobre si algún resultado raro de tu ensamblador informático es real. Tomas dos puntos, intentas la PCR y si sale bien está verificado. Se puede hacer, para asegurarse, entre varios pares de puntos.
Imaginemos un reloj para este caso, como si fuese un ADN circular (es un ARN, pero pa'l casu, patates), que es lo que describen. Bueno, pues para comprobar si ha sido un error de tu ensamblador puedes hacer un par de PCRs: 2<--->9 y 7<--->4, por ejemplo. Si ambas son positivas (dan un producto de la longitud que quieres: 7 h y 9 h), ese círculo es real. Si sólo sale una, no sabemos, pero al menos un par de esos puntos sí están relacionados y el programa de marras se ha equivocado, y si no sale ninguna entonces todo mal.
#18 Es un timo. El estudio es con las frambuesas y dicen que un 15%, pero el titular lo ponen con los arándanos que también están presentes en el estudio, pero se han centrado sobre todo en frambuesas. El arándano lo han puesto para poder venderlo en los invernaderos de Huelva que es el cultivo que está ahora de moda.
Lo que hace esto es introducir un nuevo parámetro de configuración para NAPI. NAPI, que tendrá más de dos decadas ya, es la "nueva" API para dispositivos de red que permite recibir paquetes cuando el dispositivo los recibe, reaccionando a una interrupción de red, pero también entrar en un bucle preguntándole al dispositivo si hay más paquetes disponibles. Preguntar (polling) es mejor si hay paquetes disponibles, pero un despilfarro si no los hay. En esencia, decidir entre una cosa y otra es un problema de predecir el futuro (esto implica que no hay soluciones perfectas, sólo heurísticas mejores y peores).
Esto ya es controlable con algunos parámetros. pero el nuevo parámetro permite a una aplicación configurar un temporizador que le permite permanecer en modo polling mientras tiene trabajo que hacer, el valor a configurar dependerá de lo que supuestamente tarde la aplicación en procesar los paquetes devueltos por una llamada a epoll. De este modo, mientras la aplicación esta procesando los paquetes, no revierte al modo interrupción.
docs.kernel.org/networking/napi.html#irq-suspension