Hola,
Cita:
Iniciado por amchacon 
... Y el sistema operativo no hace un while para comprobar el estado del hardware, eso era en los sistemas antiquísimos. Ahora se usan las interrupciones del procesador, la CPU puede hacer lo que se le antoje hasta que un hardware le mande una interrupción, entonces la CPU llama al sistema operativo que la procesa.
Huy allí ya nos metimos a un tema tan largo y complejo que creo que es demasiado, pero básicamente funciona así: hasta la actualidad los INT positivamente
si son un bucle infinito que está haciendo algo todo el tiempo. Pero eso es a nivel del Hardware, (por ejemplo el INT del teclado de hardware) si no recuerdo mal, hace algo parecido lo siguiente:
Código:
Hay un caracter apachado en el teclado.
Si-> paselo a una cola o buffer.
Regrese al paso 1
Y eso es repite sin parar. Pero esos son los interrputs y es otra cosa muy diferente, que normalmente la manejan los drivers específicos de cada pieza del equipo, aunque al final, el driver le pase esa información al OS cuando sea necesario. O cuando quieres sacar lo que hay en la cola llamas a una función del interrupt. Seguramente no todos los interrupts funcionan así, pero es una idea.
Al final creo que es mas complejo que eso, pero básicamente, no creo que tenga que ver con los interrupts en este caso, sería mas confuso ponerse a lidiar con el Kernel o los Drivers o cualquier otra cosa de este tipo, que simplemente esperar por el evento con el mecanismo que ya existe.
Cita:
Iniciado por Profesor_Falken Para ello el sistema operativo tiene que estar a la escucha. Y la unica forma de hacerlo es mediante un bucle. No hay magia.
Todos los sistemas que debe estar a la espera de mensajes o eventos tienen que hacer el bucle. Asi se hace con los sockets, las interfaces graficas, etc.
...
Si, pero hay que aclarar que ese bucle debe ser eficiente, no un simple bucle infinito que realiza una acción cada tiempo. Por ejemplo en los sockets, es preferible usar un blocking socket en la mayoría de los casos, el bucle no se repite hasta que haya una nueva conexión en el socket, donde lo único que hace es manejar la conexión y esperar de nuevo. (Que es muy diferente al ejemplo de los interrupts).
Cita:
Iniciado por eferion ... sino que tendrás que esperar un máximo de 2 segundos. La ventaja es el gran ahorro de CPU. ...
Tienes razón, pero como explique anteriormente eso se llama pull, y si tienes la opción de push, es mas eficiente. No espera, sino que no hace nada hasta que le llega un mensaje que lo despierta. Como un sleep() pero no por tiempo, sino hasta que algún otro proceso lo saca del sleep().
Lo que se logra con el push y en este caso el GetMessage (Dispatch, DefWndProc, etc), es algo parecido al patrón observador-observable, como un Listener que no hace nada hasta que le llega un evento.
Saludos,