Subtítulos predeterminados de Qt

Cuando inicio una nueva aplicación Qt con una cantidad mínima de código y la ejecuto, veo que hay una cantidad de subprocesos en ejecución, que como mínimo es 2 y puede ser hasta 5. Suele establecerse en 2, hasta que arrastre la ventana, en ese momento veo hasta 4 subprocesos en ejecución.

Este es todo el código que estoy usando:

#include 
#include 

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    QWidget mainWindow;
    mainWindow.show();

    return a.exec();
}

¿Alguien puede explicar por qué hay diferentes hilos y para qué es probable que sean? Originalmente esperaba solo uno, pero no me sorprendería si se usara un segundo para manejar los mensajes. Sin embargo, ¿qué podría explicar los otros hilos?

0
Todo el código de usuario se ejecuta en el hilo principal de forma predeterminada. Puede haber otros hilos, pero son utilizados por la implementación interna de Qt o por el depurador. Cuando escribe aplicaciones normales, no necesita pensar en otros hilos. Todo su código relacionado con eventos, señales o ranuras se ejecutará en el hilo principal a menos que cree nuevos hilos de usuario utilizando la API de Qt.
agregado el autor Pavel Strakhov, fuente
@tebe, como puede ver en el código de la pregunta, no hay temporizadores en uso. Todo el código que ves está allí.
agregado el autor TheDarkKnight, fuente
@PavelStrakhov, "Cuando escribes aplicaciones normales" - mi aplicación principal no es lo que se llamaría 'normal', entonces estoy creando una aplicación de prueba para ver qué está pasando con los hilos, pero no esperaba ver 5 hilos de tal código mínimo.
agregado el autor TheDarkKnight, fuente
@yosim, no estoy preocupado; esto es investigación y, curiosamente, nadie ha podido responder a esto todavía.
agregado el autor TheDarkKnight, fuente
@tebe: "si usa un QTimer :: singleShot para una llamada de tragamonedas retrasada, creo que Qt genera un hilo para la cuenta regresiva". Esto es una fantasía Por favor, deja de inventar cosas.
agregado el autor Kuba Ober, fuente
Si llegó a preocuparse por el número de subprocesos que QT usa internamente, está haciendo algo mal. si no por ninguna otra razón, porque es una implementación interna y puede cambiarse en cualquier momento. A menos que, por supuesto, quieras saber esto por curiosidad ...
agregado el autor yosim, fuente
Comentario eliminado, mayor confusión de mi parte con una implementación personalizada. Sry.
agregado el autor tebe, fuente

1 Respuestas

Ahora veo que estás preguntando por curiosidad en oposición a los problemas prácticos. Hagamos una investigación.

Intenté ejecutar tu programa en Qt 5.1 con MSVC toolkit en Windows. Configuré el depurador para interrumpir la creación del hilo. Vi que se han generado 4 hilos adicionales. 3 de ellos fueron causados ​​por Qt llamando a la función nativa de Windows RegisterDragDrop . Cuando omito la ejecución de QWindowsWindow :: registerDropSite , estos 3 subprocesos no se crean. No hay explicación sobre los hilos, incluso en la documentación RegisterDragDrop , por no decir sobre la documentación de Qt. Obviamente, este hecho puede variar al usar diferentes sistemas operativos o versiones de Qt (por ejemplo, puede construir Qt sin soporte de arrastrar y soltar). La única forma en que puede descubrir por qué los hilos se crearon para usted es un experimento. Creo que OS X también tiene algunas sorpresas para ti.

El cuarto hilo es un misterio para mí: el depurador no puede detectar cuándo se inicia. Tal vez este hilo es causado por el depurador de alguna manera.

Como esperaba, @tebe estaba equivocado al decir que Qt engendra hilos adicionales para el procesamiento de QTimer (no conozco todos los casos, pero en mi caso esto seguramente es incorrecto). QTimer usa el bucle de evento del hilo actual.

0
agregado
Gracias Pavel por tomarse el tiempo de investigar esto. Todo es interesante y la función de arrastrar y soltar se correlaciona con lo que veo, aunque, como dices, todavía hay un hilo que no se detiene en el depurador. No esperaría que los temporizadores se ejecuten en diferentes subprocesos, de lo contrario, significaría que la GUI podría liberarse de ser bloqueada mediante el uso de temporizadores, en lugar de tener que crear subprocesos adicionales. Continuaré investigando esto y veré cómo se compara OSX.
agregado el autor TheDarkKnight, fuente