Informatique

DarKwings : Les pipes est compagnie, c'est posix (donc ça passe partout de linux à darwin en passant par bsd). L'API linux correspond à ce que dit la norme afaik. Après, tu peux toujours me trouver de petites variations, mais pour une application qui a vraiment besoin de faire des IPCs, on ne doit plus être à ça près.

godrik :
« Tu n'as pas envie de passer par une API noyau pour parler avec l'application responsable de gérer le copier/coller » j'ai encore moins envie d'utiliser une surcouche pour faire ça.
Au passage, je me demande comment ça se fait que mon copier/coller à la souris marche depuis plusieurs années sous linux sur mes machines alors que je n'installe pas dbus…

« Je parle de la communication entre les applis de haut niveau. » justement, moi je dis que ces applications n'ont pas besoin de communiquer entre elles.

Question qui n'a rien à voir avec le débat actuel ^^°

Vous savez comment lancer une fonction en "background" en C ?

Je tente de m'expliquer :

J'ai une fonction qui effectue un traitement relativement long (2-3 secondes), mais j'aimerai de pas avoir à l'attendre pour poursuivre. D'autant plus que ce traitement est secondaire.

J'avais pensé utilisé un fork, le problème c'est que ça me crée une nouvelle pile mémoire, et donc je ne peux pas updater les données de mon père (ou alors je m'y prends mal).
J'ai donc utilisé des threads, mais ils sont "bloquants" (ie. c'est le même résultat que sans threads).

il faut utiliser des threads pour faire ca.
les threads ne sont pas bloquant parcontre il faut gerer leur synchronisations.
Si tu as besoin d'un coup de main, je suis pro en thread

Jackass059 : je savais bien que tu finirais par donner cet exemple.
Si tu veux mon avis, ce que tu as fais est très chouette. L'idée d'afficher une image correspondant à la musique qui est en train d'être jouée est excellente. Mais c'est "fait à l'envers".

Soit on décide que rhythmbox est le "serveur multimedia" et dans ce cas, l'affichage de l'image devrait être géré directement par lui.

Soit on décide que rhythmbox est juste un outil pour configurer sa playlist et que l'ensemble du multimedia est géré par une autre application qui fait office de "serveur multimedia". Dans ce cas, on se retrouve dans un cadre similaire à mpd/mpc/cie où tout passe par le serveur et la communication se fait via le réseau.

Bref, soit tu fais un gros machin qui fait tout (et donc tu n'as pas besoin de comm), soit tu communiques via le réseau. Mais il n'y a pas d'IPC au sens propre là dedans. Et je pense que toutes les applications de haut niveau devrait être conçues suivant l'un des deux modèles (de préférence, le deuxième qui permet tous les trucs chouettes que tu imagines avec ton modèle du pipes entre "fenêtres").

[...] l'un de ces deux modèles [...]

je suis assez d'accord avec toi chris, je ne vois pas convaincu du bien fonde de modele plus complique que le modele client/serveur.

Je veux bien un coup de main pour les threads, parce que ça fait quelques temps que je suis "bloqué" sur ce problème.

Voici le bout de code incriminé :

http://pastebin.com/m1b48fa34

Sachant que la fonction _check_cover_is_present est lancée de la sorte :

g_timeout_add (1000, (GSourceFunc) _check_cover_is_present, (gpointer) NULL);

Le principe : certains lecteurs/plug-ins téléchargent les pochettes, du coup je boucle jusqu'à ce qu'ils aient terminé le téléchargement, et j'update mon dessin avec la pochette kivabien.
Mais certains lecteurs ne téléchargent pas les images (ou mal). Du coup, j'ai ajouté mon propre "moteur de recherche" (le else if).
Pour ça, je récupère un xml sur amazon, puis je récupère une url dans ce même xml, et je télécharge l'image. Ce sont ces deux téléchargements successifs qui sont "longs".

J'ai bien créée un thread, mais il attend que la fonction que je lui demande d'exécuter soit terminée avant de me rendre la main

mon dieu, c'est quoi ce thread pas posix !!
Ce truc ne devrait pas etre blocant.
Cependant, tu utilises mal le retour d'erreur.
le parametre n'est modifie que si la fonction renvoie NULL.
c'est donc if (pThread == NULL) std::cerr<<"COIN<<std::endl;

tu peux verifier si c'est bien bloquant en affichant un message juste apres ton appel a g_thread_create

Ce qui peut arriver c'est que la fonction _cid_proceed_download_cover prenne un mutex quelque part et que le reste de ton appli cherche a prendre le meme mutex. Du coup, tu as l'impression que l'execution est serialise.

C'est quoi l'interet de ça par rapport a pthread?

Chris_27> L'interet c'est d'en faire abstraction peut être, enfin je ne sais pas si dbus est plus simple a coder que l'API Linux.

DarKwings > au final, est-ce vraiment de l'abstraction ? On part des IPCs au niveau du noyau pour arriver à des IPCs entre application haut niveau. Moi j'appelle ça de la traduction, mais pas de l'abstraction. L'abstraction, ça serait de dire que les applications haut niveau qui doivent communiquer entre elles le font via le réseau (dans un sens assez large, à définir). On revient à un modèle client/serveur.

Au passage, je tiens à faire remarquer que, chez les gens bien qui font des micronoyaux, même le bas niveau fonction sur le modèle de client/serveur.

DarKwings, je ne suis pas bie sur. Il semble y avoir une ou deux "nouvelles primitives" pour t'economiser le travail de un ou deux comportement classique.

Mais c'est assez fatiguant je trouve cette re-encapsulation systematique des libs. Ca rajoute des surcouche pour rien et tu risque d'emerder le developpeur qui va se retrouver avec des pool de thread gtk de thread sdl mais aussi de thread je-sais-pas-quoi.
Bref, fuck them.

En quoi c'est pas posix ?

En effet, si j'ajoute un debug au dessous de mon thread, j'ai bien une exécution parallèle.
Cependant, ce thread est en "conflit" avec cet autre thread :

http://pastebin.com/m4ea04c38

(j'ai une fonction qui s'occupe de traitement du dessin, une qui s'occupe de lancer les boucles de dessin, et une qui lance l'animation dans un thread pour ceux qui ont un proc multi-coeur)

Pour la petite histoire, les différentes animations peuvent être lancées en concurrence sans aucun problème. Mais quand le thread de téléchargement est lancé, l'animation se fige :/

Il y a moyen de récupérer tout le code quelque part ?

jackass, je refactor en ce momnet un de mes codes bien chaint et complique.
Je regarderais ce soir ( EST ). Tu as un code complet quelque part, je peux tester ca se soir en vrai si tu veux. (ici, j'ai une vielle centos toute pourri, et je doute que pkgsrc soit assez fort/bien configure pour installe amarok).

est ce qu'il y a un canal IRC "associe" au forum ? sur quel serveur ?

Euh… c'est un drôle de moment pour poser cette question.

Il y en a un en sursis à irc.jeuxvideo.com (canal #linux). On est en train de migrer temporairement vers irc.deblan.fr (même canal).

Tiens, le chan irc ça peut m'intéresser.

Pour le code complet, vous pouvez récupérer l'archive cid-v2.tar.gz ici : ftp://https://www.jeuxvideo.com//ftp.berlios.de/pub/cid/

Bon, j'ai pas pris la peine de nettoyer le dossier... donc l'archive est un peu lourde.
Dans le README sont indiqués les paquets nécessaires.

Les fichiers qui "parlent" de threads sont : cid-callbacks.c et cid-animation.c
J'ai ajouté en plus cid-asynchrone.c qui est une boîte à outils pour lancer des threads

Autre remarque, pour les animations les threads sont optionnels, j'ai donc désactivé les threads, mais mon animation se fige quand même

Ah oui, au fait. Pas besoin d'amarok ou autre. Dans la config tu peux choisir "monitor player : none".

Dans ce cas tu n'auras pas les animations de rotation et de fondu enchaîné, mais tu auras l'animation de focus.

Par contre, pour le téléchargement c'est en effet mieux si tu monitores un lecteur. Mais au pire, tu peux renseigner les valeurs en dur dans le code pour télécherger une pochette

il m'a l'air tout casse ce ./configure, je n'ai aucun des paquets qu'il demande dans ma distribution (ubuntu, la beta de jaunty)...

salut amis linuxien ,
Avec la nouvelle version d'ubuntu, arrivera l'ext4 et j'aimerais bien en profité donc formatage en vue, seulement voilà mon "/" et mon "/home" son sur la même partition (ben oui j'ai pas séparé j'étais un gros n00b à l'époque où j'ai installé )
Alors je voudrais savoir si c'était possible de sauvegarder mon "/home" sur clé ou autre pour le restauré une fois ma partition linux formaté et ubuntu 9.04 installé