Forum Programmation.c Threads

• # pthread_create

  Posté par cho7 (site web personnel) le 04 décembre 2005 à 18:33. Évalué à 3.

  

  plop,
  
  t'as pas du chercher beaucoup quand même.
  un simple C thread dans google me retourne une platrée de liens, dont entre autre celui là : http://www.mit.edu:8001/people/proven/IAP_2000/basic_example(...)
  
  Voilà, en esperant que ca t'aide.

  • [^] # Re: pthread_create

    Posté par David Decotigny (site web personnel) le 06 décembre 2005 à 10:17. Évalué à 1.

    

    Oui. On encore, si c'est un simple truc graphique, il y a certainement une boucle d'evenements. Dans toutes les bibliotheques graphiques (... que je connais) il y a moyen de programmer un "timeout", ie de dire au bidule d'executer une routine regulierement quand il n'y a pas d'evenements GUI a traiter. Genre en gtk c'est gtk_timeout_add() de mémoire, en fltk c'est Fl::add_timeout, en Fox c'est FX::FXApp::addTimeout, en Qt c'est QTimer, etc. Bref, en général, pas besoin de threads.

• # Plus simple

  Posté par ondex le 04 décembre 2005 à 18:40. Évalué à 3.

  

  Je n'y ais pas beaucoup réfléchi mais ça doit être facilement faisable avec les signaux.
  
  Tu créé une fonction qui change la couleur de ton logo à chaque fois qu'elle est appelée. Tu pose un handler sur le signal SIGALRM avec ta fonction. Pour générer le signal :
  http://www.mkssoftware.com/docs/man3/alarm.3.asp

• # Threads, toussa ...

  Posté par Obsidian le 04 décembre 2005 à 18:44. Évalué à 4.

  

  Tu peux effectivement lancer un second thread indépendant du premier pour aller modifier des choses, mais si c'est ton seul objectif (c'est-à-dire que ça n'a pas de vocation éducative), tu risques d'aller au devant de pas mal d'ennuis : race conditions, signaux reçus par un fils mort, deadlocks, TLS, segments de mémoire partagée non partagés, etc.
  
  En fait, il faut savoir à l'avance pourquoi on a beosin d'un thread. Si on se retrouve à envisager cette solution à postériori pour régler un problème, il y a de fortes chances pour qu'il s'agisse en fait d'une grosse erreur de conception du programme initial.
  
  Le multitâche coopératif est, depuis les systèmes d'exploitation de récente génération, devenu synonyme de ringardise et de fiabilité douteuse mais en fait, au sein d'un même programme où les différentes fonctions peuvent se faire confiance mutuellement, c'est souvent le moyen d'atteindre l'efficacité la plus haute.
  
  Essaie plutôt d'arriver toi-même au concept de boucle principale, c'est ce sur quoi s'appuie tout le multitâche. En gros, tu fais ta propre boucle qui fait successivement tous les actions à effectuer « simultanément », et parmi elles, le test des actions utilisateur qui te permettront de passer à l'étape suivante.
  
  Bon courage.

• # Threads : GLib ?

  Posté par mrlem (site web personnel) le 18 décembre 2005 à 20:36. Évalué à 0.

  

  Pour ma part, pour les threads (et plein d'autres choses bien sûr), si je suis en C, j'aime bien passer par le GLib (comme ça mon appli ne dépend pas d'une lib de threads spécifique) : la référence GLib sur les threads : http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.htm(...) pour faire bref et te donner une idée de la manière dont ça s'utilise : 1. tu fais une fonction ma_fonction() qui procède au traitement qu'effectuera ton thread. 2. dans ton fichier qui lance le thread, tu fais un truc du genre (attention, cela implique que tu disposes de la glib avec les includes) :

  #include <glib.h>
  ...
  if (g_thread_supported())
  {
    g_thread_init(NULL);
    mon_thread = g_thread_create(ma_fonction, NULL, FALSE, NULL)
    // C'est un (GThread *)
  }
  

  Attention, ce n'est qu'un morceau de code simple, voir simpliste (i.e. pas de passage de paramètre à la fonction, pas de boucle en mode thread safe, ...). Je t'encourage vivement à lire des docs sur les threads, et si tu choisis la Glib, bien regarder la référence de l'API des threads : par contre c'est vrai qu'elle manque de tutoriels...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.