IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Threads & Processus C++ Discussion :

multithread, singleton et exit


Sujet :

Threads & Processus C++

  1. #1
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut multithread, singleton et exit
    Bonjour.
    j'ai une dll qui utilise un singleton pour manager des ressources. Ces ressources instancient des std::thread, std::mutex et std::shared_mutex.

    Le singleton est instancié lors de l'appel à une fonction static

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    class singleton
    {
    public
        static singleton &current()
       {
            static singleton _singl;
            return _singl
       }
    };
    Malheureusement, ceci pose problème si un utilisateur appel la méthode exit().

    Lors de l'appel à exit, la destruction du singleton crash car les thread se sont arrêtés sans libérer les mutex.
    La seule manière que j'ai trouvée est de modifier l'instanciation du singleton en utilisant un pointeur et d'ajouté une fonction pour le détruire(doit être appelé par l'utilisateur avant de sortir du main). Mais lors d'un exit rien n'est libéré proprement.

    Y a t'il une possibilité d’empêcher l’arrêt brutale des thread lors de l'appel à un exit et de pouvoir libérer proprement les données de ma dll?

    merci,
    Yan

  2. #2
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Bonjour,

    La solution est probablement de remplacer l'appel de exit par le lancement d'une exception.
    Si le code utilise correctement le RAII, alors les ressources seront libérées au fur et à mesure que l'on remonte dans la pile.

  3. #3
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Est-ce que atexit() pourrait te permettre d'enregistrer une fonction pour gérer ce cas ?

    http://man7.org/linux/man-pages/man3/atexit.3.html

  4. #4
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    Bonjour,

    La solution est probablement de remplacer l'appel de exit par le lancement d'une exception.
    Si le code utilise correctement le RAII, alors les ressources seront libérées au fur et à mesure que l'on remonte dans la pile.
    Je n'ai pas vraiment la main sur ces parties de code :/. Mais ça serait plus propre.


    Citation Envoyé par Bktero Voir le message
    Est-ce que atexit() pourrait te permettre d'enregistrer une fonction pour gérer ce cas ?

    http://man7.org/linux/man-pages/man3/atexit.3.html
    Cette fonction est appelée après l’arrêt des thread :/


    merci

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Il est très commun de demander à l'utilisateur d'une librairie d'appeler une méthode avant toute demande, comme le CoInitialize() de COM, et après la dernière demande comme CoUninitialize() de COM.
    Donc pourquoi ne pas demander au code utilisateur de votre bibliothèque de faire de même ?

    L'utilisation de la fonction DllMain ne permet-elle pas un repli en bonne ordre ?

    Après, il reste toujours les méthodes de bourrins, à la virus, qui est de dérouter l'IAT de "exit" du programme pour que votre Dll prennent la main, mais bon, on peut commencer par gentiment demander à l'utilisateur de ne pas faire n'importe quoi, avant de sortie la bombe atomique.

  6. #6
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par bacelar Voir le message
    L'utilisation de la fonction DllMain ne permet-elle pas un repli en bonne ordre ?
    ben non car il y a des choses que l'on ne dois pas faire dans dllmain et pas forcement appelé lors de la sortie du process.

    Donc pourquoi ne pas demander au code utilisateur de votre bibliothèque de faire de même ?
    En faite j'ai une fonction qui nettoie les ressources allouées à appeler avant le return du main.
    Mais je ne m'attendais pas à ce que exit(appelé par une autre lib...) pose problème.
    Au finale, je n'avais pas pensé que lors de l'appel à un exit, les thread sont arrêtés automatiquement par le système et peut laisser des mutex bloqué et donc ne plus pouvoir désallouer certaines classe constituées de std::thread ,std::mutex,...

    Et donc devoir gérer le singleton différemment que

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    class singleton
    {
    public
        static singleton &current()
       {
            static singleton _singl;
            return _singl
       }
    };
    pour avoir des cas où on ne le détruit pas.

  7. #7
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 548
    Points
    10 548
    Par défaut
    Citation Envoyé par yan Voir le message
    Au finale, je n'avais pas pensé que lors de l'appel à un exit, les thread sont arrêtés automatiquement par le système
    Lorsque tu quittes, ce n'est pas le thread principal (ou le thread de la .dll) qui envoie un message "quit"/ "stop"/ ... à tous les threads créés ?

  8. #8
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par foetus Voir le message
    Lorsque tu quittes, ce n'est pas le thread principal (ou le thread de la .dll) qui envoie un message "quit"/ "stop"/ ... à tous les threads créés ?
    je ne sais vraiment qui fait quoi :/.
    Mais lorsque le destructeur du singleton de ma dll était appelé, les thread n’existaient plus et des mutex étaient locké=>crash.

    [edit]
    j'ai ajouté un exemple. Si vous ajoutez un breakpoint dans le destructeur du singleton, il ne reste que la main thread. Les autres sont killé et les mutex encore locké.
    Fichiers attachés Fichiers attachés

  9. #9
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Je suis vraiment pas fan des API en C++ pour les Dll, moi, c'est plus des API C en Dll, quitte à fournir des classes templates pour faire des wrappper.

    Avec une API C, le coup du CoInitialize()/CoUninitialize() passe bien.

    Sinon, une approche un peu moins bourrin que planquer/dérouter la fonction "exit" de l'IAT est donnée par THE Jeffrey Richter (2ème Q/R):
    https://www.microsoft.com/msj/archive/S202B.aspx

    P.S.: si l'approche de Jeffrey Richter vous semble obscure, n'hésitez pas à poser des questions ici.

  10. #10
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par bacelar Voir le message
    P.S.: si l'approche de Jeffrey Richter vous semble obscure, n'hésitez pas à poser des questions ici.
    Je veux bien un peu plus d'explication

  11. #11
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    Bon, après une relecture plus attentive de vos messages et de l'article de MSJ, et après un petit potassage de la littérature, la solution de Jeffrey Richter, bien que "simple" à mettre en place, ne sera pas bonne dans votre cas, voir même catastrophique.
    Le comportement en fin d'exécution d'un processus change beaucoup entre les différentes versions de Windows.
    Avez-vous une plateforme cible précise ? Cela donnerait plus de liberté et de possibilités.

    Si j'en crois les articles sur le sujet par Raymond Chen (Win32 pas sur l'implémentation dans la SDL), les mutex c'est les trucs les plus simple à "gérer" dans le cas d'une fin de programme.
    https://blogs.msdn.microsoft.com/old...03-00/?p=27003 (Attention, article plus à jour, il y a eu des modifications sur la manière dont le processus gère les sections critiques depuis).
    En gros, pour les mutex, ça marche tout seul, il parait.
    J'ai testé votre code sur un vieux VS2012 qui traine en changeant le chaine de compilation vers la version v110 et j'ai bien un abort en DEBUG sur le destructeur du mutex,.
    Mais cet abort n'est qu'un "sanity check" pour indiquer que c'est pas bien d'appeler le destructeur quand son compteur interne n'est pas à 0. Mais ici, ce compteur n'est pas à jour car le Kernel a déjà automatiquement libérer le mutex.
    En Release, pas de problème, ça roule.

    Avec ces informations, c'est quoi le problème précisément, qui n'est pas gérer "automatiquement" ?

    Un exemple de patching d'IAT :
    https://blog.neteril.org/blog/2016/1...-iat-patching/
    Ici, ça serait de patcher la méthode "exit" ou équivalent. (mais c'est vrai que le atexit est plus direct)
    Mais, vous pouvez pas patcher cette foutue lib qui appel "exit" comme un putain de sauvage ???

  12. #12
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    En Release, pas de problème, ça roule.
    exit se tranforme en abort... donc c'est pas mieux.


    Citation Envoyé par bacelar Voir le message
    Avec ces informations, c'est quoi le problème précisément, qui n'est pas gérer "automatiquement" ?
    que exit killmes std::thread sans que je n'ai aucun contrôle => des mutex ne sont pas libéré =>erreur.

    Citation Envoyé par bacelar Voir le message
    Un exemple de patching d'IAT :
    https://blog.neteril.org/blog/2016/1...-iat-patching/
    Ici, ça serait de patcher la méthode "exit" ou équivalent. (mais c'est vrai que le atexit est plus direct)
    atexit est appelé aprés le kill des thread. Pour 'IAT, je suis étonné que l'on peux faire des choses comme cela sans qu'un anti virus le bloque.


    Citation Envoyé par bacelar Voir le message
    Mais, vous pouvez pas patcher cette foutue lib qui appel "exit" comme un putain de sauvage ???
    Tout est possible avec les bon arguments
    mais le but est aussi de comprendre. Je pensais qu'en utilisant les std::lock_guard et autre, des problèmes comme cela n'était pas possible. Après plusieurs recherche, çà s'appel des mutex abandonné et les std::mutex ne l'implémente pas.
    Ça montre surtout que le exit n'est pas compatible avec le c++ moderne et l'utilisation du RAII.



  13. #13
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    exit se tranforme en abort... donc c'est pas mieux.
    Il n'y a pas d'abort en Release, en tout cas dans mon implémentation de la C-Runtime VS2012.

    que exit killmes std::thread sans que je n'ai aucun contrôle => des mutex ne sont pas libéré =>erreur.
    Ils le sont par le Kernel, c'est juste que la C-Runtime ne le sait pas et que la version DEBUG n'en est pas consciente et gueule.

    atexit est appelé aprés le kill des thread
    Oui, comme le DllMain, et alors ?

    Pour 'IAT, je suis étonné que l'on peux faire des choses comme cela sans qu'un anti virus le bloque.
    Si tu savais.
    Non, généralement, les anti-virus n'y voient que du feu.
    Et tu peux exclure ton environnement de travail des zones de scan de l'anti-virus, au pire.

    çà s'appel des mutex abandonné et les std::mutex ne l'implémente pas.
    Oui, mais c'est pas grave, ils utilisent ceux du Kernel qui lui l'implémente.

    Ça montre surtout que le exit n'est pas compatible avec le c++ moderne et l'utilisation du RAII.
    "exit" n'est compatible avec absolument rien, depuis l'invention de la programmation structurée, il y a fort longtemps.
    "exit" c'est CACA.

    Je ne comprends toujours pas pourquoi ne pas juste laisser pisser, en Release.

  14. #14
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par bacelar Voir le message
    Il n'y a pas d'abort en Release, en tout cas dans mon implémentation de la C-Runtime VS2012.
    ?? ben ca appel abort et stop le process.

    Oui, comme le DllMain, et alors ?
    çà résout pas mon problème. si c'était appelé avant le kill des thread, j'aurais pu faire le ménage proprement


    Oui, mais c'est pas grave, ils utilisent ceux du Kernel qui lui l'implémente.
    si je les lock pour une raison ou une autre je me retrouve bloqué indéfiniment. C'est le comportement des mutex de la std qui ne semble pas être juste un wrapper au vieux mutex.

    Je ne comprends toujours pas pourquoi ne pas juste laisser pisser, en Release.
    par ce que j'aime bien comprendre et que j'aurais préféré pouvoir nettoyer sans faire des bidouilles.

  15. #15
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    ?? ben ca appel abort et stop le process.
    Ça c'est en DEBUG, pas en RELEASE.
    Et pour la fin de processus, n'y a-t-il pas autre chose que des mutex, comme des sections critiques, ou du code qui touche à ces mutex après la fin des threads satellites ?

    çà résout pas mon problème. si c'était appelé avant le kill des thread, j'aurais pu faire le ménage proprement
    L'OS fait le travail pour toi, non ?

    si je les lock pour une raison ou une autre je me retrouve bloqué indéfiniment. C'est le comportement des mutex de la std qui ne semble pas être juste un wrapper au vieux mutex.
    Il est bien plus probable que le blocage vienne de votre code qui attend des threads déjà mort que d'éventuels mutex.

    par ce que j'aime bien comprendre et que j'aurais préféré pouvoir nettoyer sans faire des bidouilles.
    La manière "propre", c'est de ne jamais appeler exit.
    Il ne vous reste donc que les bidouilles.
    La meilleure bidouille, c'est celle qui ne fait rien.
    Normalement, en RELEASE, vous n'avez rien à faire.

    Le comportement de l'OS est là pour simplifier la tâche, et même ceux avec la tête en l'air.

  16. #16
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Exit c'est mal ça on est d'accord

    Pour le reste, pas tout à fait.
    Pour moi, dans le fonctionnement normal d'un processus c'est au développement de gérer ses ressources et non a l'OS.


    Mais bon le problème se pose à cause du exit ^^

  17. #17
    Expert éminent sénior
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Février 2005
    Messages
    5 058
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2005
    Messages : 5 058
    Points : 12 093
    Points
    12 093
    Par défaut
    c'est au développement de gérer ses ressources et non a l'OS.
    Si c'était vraiment le cas, les OS ne fonctionneraient correctement que vraiment très très peu de temps.
    Moi, Windows3.0, j'en veux plus.

    Maintenant, soyez un peu moins psycho-rigide.

    Pour éviter que l'OS soit en carafe parce qu'une équipe de développeurs ne s'est pas mise d'accord avec une autre, l'OS a fait SON job : dessouder tous les threads sauf un, libérer tous les mutex, "électrifier" les sections critiques (elles sont "libres", mais si le code y entre, c'est "process shutdown sans passer par la case départ, vous ne touchez pas 20 milles"), etc... .

    C'est à vous de faire le vôtre, qui, en RELEASE est "rien" (merci les "concepteurs" de l'OS qui sont vraiment très gentils avec les développeurs étourdis), et en DEBUG faire les bidouilles pour que sanity-check de la librairie passent crèmes.

    N'oubliez pas que le thread survivant est sur une autoroute, où il ne doit pas attendre ces camarades et que tous les feux (verrous) sont aux verts, ce qui facilite grandement le code de "nettoyage".

  18. #18
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par bacelar Voir le message
    l'OS a fait SON job : dessouder tous les threads sauf un, libérer tous les mutex, "électrifier" les sections critiques (elles sont "libres", mais si le code y entre, c'est "process shutdown sans passer par la case départ, vous ne touchez pas 20 milles"), etc... .
    Çà reste une stratégie (laisser faire l'OS). Lors d'un crash de l'application çà ne me pose aucun problème.
    Sinon a quoi se faire ..bip... avec toutes ces classes RAII ou autres outils?

    Après, la question de départ était de comprendre le "pourquoi" pour savoir "quoi faire"

    Le exit me stop net des traitements en cours dont j'aurais préféré gérer l’arrêt moi même.

    pour les info.

  19. #19
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 958
    Points
    32 958
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par yan Voir le message
    Sinon a quoi se faire ..bip... avec toutes ces classes RAII ou autres outils?
    A s'assurer du bon fonctionnement de l'appli tant qu'elle doit tourner, à commencer par ne pas consommer plus de mémoire et CPU que nécessaire, voire que disponible. Quand elle doit s'arrêter, on s'en moque royalement, on l'arrête, quelle que soit la violence employée, et l'OS nettoie le tout bien.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  20. #20
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 033
    Points : 13 968
    Points
    13 968
    Par défaut
    Citation Envoyé par Bousk Voir le message
    A s'assurer du bon fonctionnement de l'appli tant qu'elle doit tourner, à commencer par ne pas consommer plus de mémoire et CPU que nécessaire, voire que disponible. Quand elle doit s'arrêter, on s'en moque royalement, on l'arrête, quelle que soit la violence employée, et l'OS nettoie le tout bien.
    Que l'OS fasse sont travail est une chose, mais que je mes traitements s'arrêtent violemment sans que je puisse faire quelque chose en est une autre.

    Je ne comprend pas trop ce qui vous gène en faite.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Singleton et multithread
    Par totoche dans le forum Servlets/JSP
    Réponses: 2
    Dernier message: 25/05/2010, 19h05
  2. [Singleton] singleton et multithreading
    Par behess dans le forum Design Patterns
    Réponses: 17
    Dernier message: 24/09/2009, 19h33
  3. Singleton et Multithreading
    Par behess dans le forum C#
    Réponses: 22
    Dernier message: 09/09/2009, 12h09
  4. Singleton et multithreading
    Par Alp dans le forum C++
    Réponses: 17
    Dernier message: 06/08/2006, 03h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo