2009-03-12 5 views
5

Je travaille actuellement sur une application multi-thread qui serait déployée sur l'architecture bras et ppc. J'ai un problème avec pthread_cancel sur le bras.pthread_cancel se comporte différemment sur le bras et ppc?

pthread_cancel sur le bras ne se comporte pas de la même manière avec ppc. Le thread est annulé mais le destructeur de la variable locale du thread n'est pas appelé sur le bras. J'ai également essayé de définir explicitement une routine de gestionnaire de nettoyage d'annulation installée via pthread_cleanup_push. Mais il n'est pas appelé quand le thread est annulé.

Le code fonctionne bien avec ppc. Lorsqu'un thread est annulé, le destructeur de la variable locale est appelé. Et quand j'ai explicitement défini un gestionnaire de nettoyage, il a été appelé et exécuté lorsque pthread_cancel a été appelé.

Ai-je raté quelque chose? Certaines options du compilateur peut-être?

  • Langage de programmation: C++
  • Compilateurs: bras-linux-g ++/powerpc-linux-g ++
  • OS: Linux

EDIT:

J'ai trouvé une sorte de problème similaire enregistré sur ce libc bug.

L'utilisation de gcc au lieu de g ++ et l'ajout d'option de compilateur -fno-exception ont fait l'affaire. Mais je veux vraiment comprendre ce qui se cache derrière ce problème. De plus, l'exception -fno-exception signifie que je ne serai pas capable de gérer les exceptions dans mon application, pas que je l'utilise maintenant mais que je puisse être dans le futur.

Merci.

+0

Veuillez spécifier la langue et les compilateurs utilisés (pour les deux plates-formes). Cela ressemble à du C++, mais il vaut mieux être explicite. – unwind

+0

Il serait également utile de savoir quel OS comme le paquet pthread est souvent spécifique au système d'exploitation. – Benoit

+0

Je suggère également d'indiquer la version exacte du noyau Linux, le support de plate-forme cible utilisé dans chaque cas, et les versions de gcc/g ++, libc, et tout autre logiciel impliqué. Sans numéros de version précis, il est difficile de trouver de bons conseils. – jakobengblom2

Répondre

2

Annulation de fil sans l'aide de l'application est une mauvaise idée. Juste google. Il est préférable de dire au thread de se terminer en définissant une variable d'indicateur vérifiée périodiquement par le thread.

En fait, l'annulation est si difficile qu'elle a été omise du dernier brouillon C++ 0x. Vous pouvez rechercher http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html et ne trouver aucune mention de l'annulation du tout. Voici la définition de la classe de thread proposée (vous ne trouverez pas d'annulation là):

class thread 
{ 
public: 
    // types: 
    class id; 
    typedef implementation-defined native_handle_type; // See [thread.native] 

    // construct/copy/destroy: 
    thread(); 
    template <class F> explicit thread(F f); 
    template <class F, class ...Args> thread(F&& f, Args&&... args); 
    ~thread(); 
    thread(const thread&) = delete; 
    thread(thread&&); 
    thread& operator=(const thread&) = delete; 
    thread& operator=(thread&&); 

    // members: 
    void swap(thread&&); 
    bool joinable() const; 
    void join(); 
    void detach(); 
    id get_id() const; 
    native_handle_type native_handle(); // See [thread.native] 

    // static members: 
    static unsigned hardware_concurrency(); 
}; 
+0

Je me suis installé pour quelque chose comme ça. J'ai juste décidé de rester à l'écart de pthread_cancel et de tout le gâchis qu'il pourrait apporter. J'ai juste ajouté une variable de drapeau indiquant l'état du thread et vérifié l'état sur certaines zones désignées comme points d'annulation. J'ai également envoyé un SIGINT pour ne pas bloquer les appels d'E/S. De cette façon, j'aurais un contrôle total sur les points d'annulation et le fil serait capable de se terminer proprement et gracieusement tout le temps. Merci! –

Questions connexes