[SOLUCIONADO] Mantener el programa siempre en ejecucion

[shekel]

Estoy intentando mantener mi programa en c++ siempre en ejecucion.

Se trata de listar los medios conectados a la espera de encontrar que he conectado mi telefono movil..

Puedo hacer que funcione si cuanto inicio el programa ya esta el movil conectado, mi pregunta es.. ¿Cual es la forma mas eficaz para mantener mi programa siempre en ejecucion?

Estoy usando Windows 7.

He probado a usar "while (true)" pero cuando voy al administrador de tareas en la columna CPU me aparece como 99% de uso... creo que estoy haciendolo mal

[vangodp]

bueno... While true es como cuando abres el grifo de tu casa. Estas ordenando que se vacie el agua.

Si lo que quieres es solo mantenerle abierto un simple getchar() lo hace bien >_<.

Por otro lado si tu programa hace como acciones algo como...:

Código C++:

#include <iostream>
#include <windows.h>
using namespace std;
 
int main (){
    
    
    int salir = 0;
    int opcion = 0;
    do{
        system("cls");
        cout << "Elija una opcion: \n\n1-blabla \n2-lolbla \n0-salir \n\nOpcion?: ";
        cin >> opcion;
        cin.sync();
        switch (opcion) {
            case 1:
                cout << "caso1" << endl;
                break;
            case 2:
                cout << "caso2" << endl;
                break;
            case 0:
                cout << "Adios!";
            default:
                cout << " Nos vemos XD" << endl;
                salir = 1;
                break;
        }
 
    }while(!salir);
 
    cin.ignore(); //pausa
    return 0;
}
 

haz que el programa espere una orden y no consumira recursos, el bucle sin nada dentro es como hacerle trabajar sin necesidad. ;)

Suerte!

[razpeitia]

Pues claro que si, chavo obvio siempre va estar al 99% porque siempre estas procesando algo.

Para eso necesitas hacer esperar de manera eficiente por los eventos que te interesan.
Otra opción interesante que puedes tomar es como lo hacen los juegos. Ponen un delay dentro del while true para empezar a renderizar el siguiente frame.

No se que api o librería uses para realizar el trabajo, pero incluso hay listeners o callbacks que podrías usar para procesar por eventos.

[amchacon]

Hacer un bucle infinito es absurdo, lo más normal sería que el sistema "te avise" cuando se conecta un nuevo dispositivo. No me preguntes como pero debe haber alguna forma de hacerlo con las Windows API.

[razpeitia]

Iniciado por amchacon

Hacer un bucle infinito es absurdo, lo más normal sería que el sistema "te avise" cuando se conecta un nuevo dispositivo. No me preguntes como pero debe haber alguna forma de hacerlo con las Windows API.

Internamente el sistema operativo, siempre esta checando (con un ciclo infino) por evento esto se llama event loop.

[lareto]

while(true) (o equivalentes) es lo normal, con alguna clase de sleep() dentro, para que no consuma CPU. Hay un mensaje reciente sobre sleep().

[HackmanC]

Hola,

Aunque no estoy actualizado sobre el tema, posiblemente te sea de alguna ayuda.

Iniciado por shekel

Estoy intentando mantener mi programa en c++ siempre en ejecucion. ...

Hay una gran diferencia entre mantener un programa en ejecución esperando a algún evento del sistema a mantener un programa ejecutando una acción repetitivamente.

Iniciado por shekel

...Se trata de listar los medios conectados a la espera de encontrar que he conectado mi telefono movil..

Puedo hacer que funcione si cuanto inicio el programa ya esta el movil conectado, mi pregunta es.. ¿Cual es la forma mas eficaz para mantener mi programa siempre en ejecucion?

Estoy usando Windows 7.

He probado a usar "while (true)" pero cuando voy al administrador de tareas en la columna CPU me aparece como 99% de uso... creo que estoy haciendolo mal

Definitivamente la mejor opción es esperar a que el sistema operativo te avise cuando haya sucedido un evento. Usar un ciclo infinito no es buena idea en cualquier caso. Aclarando de una mejor forma, usar un ciclo infinito con while(ture) no es buena idea en cualquier caso, usar un ciclo infinito que espere a recibir un mensaje es lo mas adecuado.

Dependiendo del tipo de evento que deseas tendrías que buscar la librería que mejor se ajuste a tus necesidades. Por ejemplo, si solamente quieres saber si se ha montado un volumen, con la ventaja que lo puedes obtener en el GetMessage de tu aplicación puesto que es un WM_, o cuando se carga una nueva unidad de disco:

https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

O si quieres que te avise cuando se ha conectado un nuevo dispositivo:

https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

Que son dos cosas muy diferentes, el primero te avisa de unidades y puntos de montaje, mientras el segundo te avisa de dispositivos, como por ejemplo cuando configuras Android con el protocolo MTP.

Iniciado por razpeitia

Internamente el sistema operativo, siempre esta checando (con un ciclo infino) por evento esto se llama event loop.

Solamente como aclaración adicional, hay que tener en cuenta que no es exactamente lo mismo, el Event Loop de Windows no es un simple ciclo infinito. Sino todas las aplicaciones de Windows consumirían el 100% del procesador todo el tiempo. Con la instrucción :

while (GetMessage(&msg, NULL, 0, 0)) { ... }

Lo que hace el sistema operativo es "esperar a recibir un mensaje" .. GetMessage() .. eso permite que el sistema le de un time slice a cada aplicación y el SO no se quede bloqueado. Lo que permite que la aplicación no haga absolutamente nada durante algunos momentos, mientras espera el GetMessage, es decir, puede estar sin consumir recursos del sistema mientras espera que se conecte el teléfono.

https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

Iniciado por lareto

while(true) (o equivalentes) es lo normal, ...

No sé específicamente a que te refieres con while(true) .. pero desde mi punto de vista es lo peor que puedes hacer en una aplicación, en el lenguaje que sea, para hacer lo que sea, a menos que haya un break o un salto de control por otro medio, y no se quede bloqueado todo el sistema.

Técnicamente son dos tecnologías diferentes, el pull y el push. Por ejemplo, estar chequeando cada 5 segundos si hay datos es un pésimo comportamiento (pull). Mientras que esperar hasta recibir un mensaje con GetMessage es mas adecuando (push).

Saludos,

[lareto]

Iniciado por HackmanC

Hola,
No sé específicamente a que te refieres con while(true) .. pero desde mi punto de vista es lo peor que puedes hacer en una aplicación, en el lenguaje que sea, para hacer lo que sea, a menos que haya un break o un salto de control por otro medio, y no se quede bloqueado todo el sistema.
Saludos,

Lo que decía, y sostengo, es que while(true) es una formal normal, habitual, de mantener un proceso activo a la espera de un evento; por ejemplo... en
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx
hay un ejemplo casi completo de lo mismo que se pregunta, donde se procesa la cola de mensajes con un ciclo while infinito (infinito, claro está, hasta el momento en que deja de serlo; en este caso, por la llegada de WM_QUIT).

donde dice:

Código C++:

while( (retVal = GetMessage(&msg, NULL, 0, 0)) != 0 )
{
    if ( retVal == -1 )
    {
        ErrorHandler(TEXT("GetMessage"));
        break;
    }
    else
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
}
 

podría, también, haber puesto un equivalente:

Código C++:

while(true) 
{ 
    retVal = GetMessage(&msg, NULL, 0, 0);
    
    if(retVal == 0) 
    {
        break;
    }
    else if ( retVal == -1 )
    {
        ErrorHandler(TEXT("GetMessage"));
        break;
    }
    else
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
}
 

Y no sé si es lo mejor que puede hacerse, pero seguramente no es lo peor; al menos yo puedo pensar en cosas peores sin mucho esfuerzo.

[razpeitia]

Iniciado por HackmanC

Solamente como aclaración adicional, hay que tener en cuenta que no es exactamente lo mismo, el Event Loop de Windows no es un simple ciclo infinito. Sino todas las aplicaciones de Windows consumirían el 100% del procesador todo el tiempo. Con la instrucción :

Claro que no, pero la suma de porcentaje de CPU, si daría 100% lo cual es correcto.
Porque crees que existe un proceso inactivo del sistema ocupando tanto cpu.

[HackmanC]

Hola,

Iniciado por lareto

... Y no sé si es lo mejor que puede hacerse, pero seguramente no es lo peor; al menos yo puedo pensar en cosas peores sin mucho esfuerzo.

Ciertamente, también por eso escribí "...no se a que te refieres exactamente con while(true)...", es decir, allí cambia la cosa, pasaste el GetMessage dentro del ciclo.

Iniciado por razpeitia

Claro que no, pero la suma de porcentaje de CPU, si daría 100% lo cual es correcto.
Porque crees que existe un proceso inactivo del sistema ocupando tanto cpu.

Exactamente, básicamente era una aclaración sobre lo que habías escrito.


Resumiendo, es cierto que un ciclo infinito, pero lo que sucede dentro de ese ciclo infinito es lo importante. A lo que me refería principalmente, es que según lo que comenta shekel, su proceso consume 99% de CPU.

Es decir, lo que está haciendo es seguramente,

Código C:

void IntentarLeerDispositivo() {
  // intentar leer si el dispositivo está conectado.
}
 
while(true) {
  IntentarLeerDispositivo();
}
 

Eso es pésimo para el sistema operativo, si fuera una aplicación de 16 bits, en Windows 3.1 votaría completamente el OS, posiblemente tenías que apagar la PC con reset. Ahora, con 32 y 64 bits y múltiples Cores, ya no es tan visible el problema, te da tiempo de entrar al Task Manager y detener el proceso.

Ahora, lo que hace GetMessage() es bastante complejo, normalmente dentro de un ciclo infinito, pero no es un simple while(true) común y silvestre, a eso me refería básicamente, sin el GetMessage de por medio es lo peor que puedes hacer.

Saludos,

[amchacon]

Iniciado por razpeitia

Claro que no, pero la suma de porcentaje de CPU, si daría 100% lo cual es correcto.
Porque crees que existe un proceso inactivo del sistema ocupando tanto cpu.

No va por ahí la cosa.

El proceso inactivo del sistema es un proceso que se ejecuta cuando no hay NINGÚN otro proceso en el planificador, lo único que hace ese proceso es poner la CPU en modo ahorro de energía.

Comprueba la frecuencia a la que se pone la CPU en iddle y en FULL. Verás que hay una diferencia significativa (bueno, y además se calienta bastante).

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.

[Profesor_Falken]

[...]entonces la CPU llama al sistema operativo que la procesa

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.

Un saludo

[eferion]

Un "truquillo" que puedes hacer para evitar un consumo tan alto de CPU es introducir un tiempo de espera con un sleep, de tal forma que, por ejemplo, únicamente realices la consulta una vez cada 2 segundos. En este caso la detección de la conexión no se realiza instantáneamente, sino que tendrás que esperar un máximo de 2 segundos. La ventaja es el gran ahorro de CPU.

Para evitar que este sleep te congele toda la aplicación te recomiendo mover el bucle de consulta a un hilo secundario.

[HackmanC]

Hola,

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.

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).

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,

[eferion]

Iniciado por HackmanC

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.

Tan crítico es el rendimiento? en este caso lo dudo. Está claro que dejar al SO la responsabilidad de "despertarte" cuando puede ser lo ideal. Sin embargo hay que tener en cuenta otras consideraciones:

* La espera puede no permitirte abortar el proceso de una forma sencilla
* La solución, desde luego, no es portable
* La solución es más compleja de implementar y lo mismo no es necesario

[amchacon]

Iniciado por eferion

Tan crítico es el rendimiento? en este caso lo dudo. Está claro que dejar al SO la responsabilidad de "despertarte" cuando puede ser lo ideal. Sin embargo hay que tener en cuenta otras consideraciones:

* La espera puede no permitirte abortar el proceso de una forma sencilla
* La solución, desde luego, no es portable
* La solución es más compleja de implementar y lo mismo no es necesario

Como se nota que te dedicas a esto profesionalmente ;)

[HackmanC]

Hola,

Tienes razón, pero hay varios detalles específicos en este caso, es decir, según la pregunta inicial hay que tomar en cuenta lo siguiente:

Iniciado por eferion

Tan crítico es el rendimiento? en este caso lo dudo. Está claro que dejar al SO la responsabilidad de "despertarte" cuando puede ser lo ideal. Sin embargo hay que tener en cuenta otras consideraciones: ...

No se que tan crítico sea el rendimiento, pero hagamos suposiciones, la pregunta inicial dice que quiere saber 'cuando se haya conectado el dispositivo móvil', por supuesto que puede consultar cada 2 o 3 segundos si el dispositivo ya se conectó o no, y en la actualidad, con procesadores de 64 bits y varios núcleos, el rendimiento no va a ser tan malo.

La cuestión es que se preguntó ¿cual es el mejor método?

En este caso seguir las instrucciones de como hacer una aplicación para Windows, recibiendo el (WM_) mensaje de dispositivo correspondiente es lo mas correcto. Hay muchos métodos más, pero desde mi punto de vista, es la forma mas adecuada de funcionar de una aplicación diseñada para Windows. Incluyendo que la ventana que posiblemente tenga que crear no necesariamente tiene que ser visible.

Iniciado por eferion

...
* La espera puede no permitirte abortar el proceso de una forma sencilla ...

Realmente la aplicación delega el control a Windows mientras espera por el mensaje, pero si quieres abortar es de lo mas simple. Suponiendo que creara una ventana entonces cualquier ventana de Windows se puede abortar en cualquier momento, con el botón Cerrar, eso envía un PostQuitMessage y todo termina o también puede agregar un botón y recibir el evento del botón. Si quiere abortar en la consola con Ctrl+C solo debe recibir los eventos correctos, como cualquier otra aplicación.

Aprovechando voy a agregar algo adicional, nunca se va a producir un abort realmente, es el flujo natural de haber usado GetMessage y el Event Loop de Windows correctamente. Lo interesante de esa forma de manejar los mensajes es que recibes todos los mensajes en un mismo loop. Por lo tanto, aunque no recibas un mensaje de que ya se conectó el teléfono puede ser que recibas un mensaje que se presionó un botón (cualquier botón) o que se presionó el botón de Cerrar de la ventana. O inclusive puedes recibir eventos de que el sistema operativo se va a apagar y puedes cerrar tu proceso tranquilamente, normalmente.

En todo ese proceso puedes recibir los eventos que quieras o dejar de recibir cualquier evento que no deseas, eso significa que antes de comenzar a recibir eventos de conexión de dispositivo te registras para recibirlos. O cuando ya no quieres técnicamente no tienes que abortar nada, simplemente te desregistras de recibir esos eventos y todo normal. Es lo normal de las aplicaciones para Windows en C, en C++ podrá variar un poco, por ejemplo si se hace uso de MFC u otras librerías.

Como los eventos llegan en cola posiblemente presionaste el botón de desregistrarte de recibir eventos del dispositivo (Abortar, Cerrar o cualquier otra cosa, que definiste en la ventana) antes de recibir el evento y si después llega el evento de dispositivo ya no lo recibes, técnicamente no abortaste nada, simplemente le indicas que ya no te interesa recibir esos mensajes, y en cualquier momento puedes detener tu aplicación normalmente, inclusive cuando detecte que se retiró el dispositivo, porque llegó el mensaje si ese fuera el caso, o cuando tu quieras. (Una vez limpiando los recursos usados y desregistrandote de cualquier cosa que te hayas registrado).

Aunque lógicamente todo esto va a variar dependiendo de muchos factores.

Iniciado por eferion

...
* La solución, desde luego, no es portable
...

Cierto, pero el usuario mencionó explícitamente Windows 7 en el mensaje inicial.

Iniciado por eferion

...
* La solución es más compleja de implementar y lo mismo no es necesario

Tienes toda la razón, lo mas simple ya lo mostró lareto en el vínculo de su último mensaje, y no es tan simple, pero es la manera mas adecuada de funcionar de una aplicación para Windows, es decir, Windows API 101 para detectar cuando un dispositivo se ha conectado de la manera adecuada.


No te quiero llevar la contraria, posiblemente las necesidades de shekel no son esas, posiblemente se la hace muy complicado, posiblemente no es lo que se requiere en este caso, pero según la pregunta inicial, desde mi personal punto de vista, el vínculo de lareto es la respuesta mas adecuada, que es básicamente lo que propuse inicialmente.


Saludos,

[eferion]

Iniciado por HackmanC

No te quiero llevar la contraria, posiblemente las necesidades de shekel no son esas, posiblemente se la hace muy complicado, posiblemente no es lo que se requiere en este caso, pero según la pregunta inicial, desde mi personal punto de vista, el vínculo de lareto es la respuesta mas adecuada, que es básicamente lo que propuse inicialmente.

Estoy totalmente de acuerdo contigo. Al final va a depender de las necesidades y conocimientos del que lleva a cabo el proyecto... copiar un código que no se entiende no es jamás una buena opción. Dado que no conocemos las aptitudes del interesado, lo mejor es poner todas las opciones que se nos ocurran y ya será decisión suya elegir cual es la mejor opción.

En el fondo sí creo que aprovechar las bondades del SO es una buena opción, pero también es cierto que para hacer eso es estrictamente necesario conocer bastante bien el terreno sobre el que te estás moviendo. El jardín en el que te puedes meter si vas sin saber, simplemente copiando y pegando, puede ser antológico.

Si alguien no se siente muy seguro con esta opción, siempre puede empezar por mecanismos más sencillos y fáciles de entender y, posteriormente, perfeccionar el código. Es una forma de hacer las cosas que lleva más tiempo, pero se aprende muchísimo más y además es más satisfactorio.