Application multithread à la séquence de démarrage - C++/Debian

Question

J'ai ce problème obscur depuis 2 jours: j'ai créé une application de lancement au démarrage en C++ sur un système Debian, qui fonctionnait parfaitement jusqu'à ce que j'intègre des éléments multithread.

• Il y a seulement 2 fils (1 principal et 1 enfant)
• I inclus -lpthread et -pthread dans le makefile
• J'ai essayé à la fois /.config/autostart et les méthodes de fichiers .desktop (même résultat)
• le programme est lanched avec sudo
• Il n'y a pas d'erreur/accident partout, le thread principal fonctionne bien, mais le thread enfant court 1 itération ne s'arrête alors pour une raison
• a même essayé d'ajouter un peu de sommeil dans la séquence de démarrage lxsession
• Si je lance la même ligne de commande que dans le fichier autostart d'un terminal (sudo ou non), cela fonctionne parfaitement.

Cela fait 2 jours et je n'ai aucun indice! Si quelqu'un a déjà vécu cela ou peut trouver une certaine logique, je serai toujours reconnaissant.

Answer 1

Merci à tous pour vos suggestions.

J'ai trouvé une "solution": l'exécution du programme de démarrage dans un terminal ('@lxterminal -e url/to/programme &' dans Autostart de lxsession) au lieu de fond semble fixer une certaine façon. Il n'y a pas d'interface graphique si ... c'est un service.

La logique multithread n'est pas en faute ici, pas mon premier tir, et je veux vraiment garder cette fonctionnalité (@Mike Robinson).

Je vais reconsidérer l'utilisation de sudo comme suggéré aussi, ce qui semble sommaire tout bien considéré. Cela pourrait le faire fonctionner en arrière-plan. merci @ datenwolf.

Answer 2

Il me semble que vous avez simplement ... un bug dans votre nouvelle logique. Vous avez fait une erreur dans la conception de votre logique multi-thread, de sorte que le thread enfant n'exécute qu'une seule itération. (Ou, beaucoup plus probable, cale dans une attente infinie Attend un événement qui n'est jamais signalé, un sémaphore qui n'est jamais levé, une file d'attente qui est sèche et n'est jamais remplie, etc.)

Nous pouvons vous aider davantage si vous postez des extraits du code en question ... illustrant seulement comment le fil de l'enfant est lancé et comment il interagit avec le parent. (Condition-variables, sémaphores, et ainsi de suite, qui est probablement où se trouve le point crucial de votre erreur.)

Je suggérerais que "tout le reste n'est pas pertinent." Vous n'avez pas besoin de "dormir dans la séquence d'amorçage" (si la séquence attend que votre programme soit terminé, et si nécessaire). Je suggère qu'il me semble que vous avez simplement ... bug dans votre nouveau code qui introduit le multi-threading.

Et vous voudrez peut-être envisager si le multi-thread est avantageux, étant donné que vous avez eu une version non-threaded de la même chose qui a fonctionné correctement. Si le traitement qui doit être fait a été fait (avec succès) par un seul thread, un traitement de ce type peut ou non être traité de manière plus avantageuse par les threads "n". est-ce que vous trouvez et corrigez ce bogue, ou est-ce aussi bien d'abandonner le changement et de revenir à ce qui a fonctionné? Seulement vous pouvez décider que ...