Bon, alors voila mon probleme :
J ai d un coté un processus de monitoring system (genre bande passante dispo, memoire libe, charge CPU etc.)
de l autre, une application (par exemple player video en train de lire une video streamée)
 
Je veux que 1) l appli puisse consulter les valeurs recuperee par le processus de monitoring et 2) que le processus de monitoring puisse prevenir l appli pour certains evenement (genre bande passante < XX KBits/s)
 
Comment je communique entre les deux pour que ca amrche bien ?
 
J ai regardé les signaux noyaux mais y a que 2 signaux utilisateurs d apres ce que j ai vu (donc pas suffisant )
 
Voila, j aimerais un truc propre ? je vous demande pas de ma le coder, juste les outils bien pour ca
 
Merci

un bête pipe suffit pas ?

T'as différents moyens :
- pipes
- segment de mémoire partagé
- sockets (passe par la couche réseau)
- envoi de messages
 
Maintenant, reste à voir lequel est le plus approprié.

En fait je pense passer par un fichier pour les consultations de valeurs (en fait le moniteur ecrit un fichier XML avec toutes les caracteristique) avec un bete mutex pour pas faire de betises
Par contre c pour les "callbacks" du moniteur vers l appli que je sais aps trop comment faire...
 
Pipe : pas sur que ce soit adapté
Mem partagée : pour remplacer le fichier oui ca peut le faire pour accelerer le bazard
envoi de message : ca me aprait le mieux en fait
sockets : euh g deja assez de trucs sur l interface reseau pour pas foutre le souck en plus

 
Ben si t'as un thread qui passe son temps sur un select(), ca peut le faire. Quand le select se debloque (si tu mets pas de timeout, evidement), c'est que y'a des données sur le pipe. Dans le pipe tu peux mettre un truc qui sera a interpreter pour savoir le type de callback a appeler par exemple.

Le truc c qu au final faut que ca puisse recevoir et envoyer de la video par interface sans fil sur un pda donc vraiment short ressource
car pas bcp de bande passante donc faut bcp compresser donc faut bcp de temps CPU... donc en plus faut que ce soit bien rapide
 
MAsi je vais jetter un coup d oeil sur les pipe voir si ca peut le faire

nono a écrit a écrit : Le truc c qu au final faut que ca puisse recevoir et envoyer de la video par interface sans fil sur un pda donc vraiment short ressource [...] MAsi je vais jetter un coup d oeil sur les pipe voir si ca peut le faire

 
Tu t'inquietes du temps que va prendre la lecture d'un pipe, alors que tu as un fichier xml a parser a coté ???  

Pour ce qui est de prévenir l'appli, un signal me parait bien. Ca évite d'avoir un thread qui doit rester bloqué à attendre des données.

lorill a écrit a écrit :     Tu t'inquietes du temps que va prendre la lecture d'un pipe, alors que tu as un fichier xml a parser a coté ???

euh ouais c sur...
Mais le parsing du XML se fera en theorie qu au lancement des appli et apres ce sera tres tres rare...
Par contre les callback ce sera souvent c pour ca que pour le moment je m occupe pas trop de ca....

Apres reflexion, je reviens en arriere et je me dis que socket c pas si mal...
Ca me permettrais de recuperer les infos moniteurs du serveur video par exemple etc... donc en fait ca me plait
vendu

Si c'est sur la même machine, c'est une surcharge par rapport au pipe. M'enfin si ca te plait, je suis pas la pour te vendre mon pipe non plus (j'en ai des pas cher très peu servi en stock )

lorill a écrit a écrit : Si c'est sur la même machine, c'est une surcharge par rapport au pipe. M'enfin si ca te plait, je suis pas la pour te vendre mon pipe non plus (j'en ai des pas cher très peu servi en stock )

Ouais c peut etre une surcharge (meme surement) masi au final c plus ouvert
donc quitte a surcharger bah autant que ca puisse me permettre de le faire a distance aussi
 
PS : question annexe : qd on utilise des sockets, etre en IPv4 ou IPv6 ca change bcp de choise sur le code ou aps ?