|
Page : 1 2 Page Précédente | |
Auteur | Sujet : Algorithme parallélisé: Je n'arrive pas à l'écrire avec fork() |
Publicité | Posté le 01-10-2007 à 16:24:57 |
Taz bisounours-codeur | oui ça se fait, maintenant faut me laisser le temps de retrouver comment |
Sve@r |
Message cité 1 fois Message édité par Sve@r le 01-10-2007 à 18:55:54 --------------- Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche. |
sigmatador |
Sauf si je me trompe, certes FILE* n'est qu'un pointeur vers une structure, mais vu que fopen utilise open, la structure FILE doit bien contenir un index de la table des descripteurs de fichiers associée au processus courant, index qui n'aurait aucun sens (en tout cas aucun sens cohérent) dans un autre processus ayant forké avant l'ouverture du dis fichier (la table des descripteurs de fichiers étant propre à chaque processus).
Perso je connaissais rien aux pipes, j'ai regardé des exemples sur le net, quand plusieurs processus cherchaient à écrire parallèlement dans un même pipe, l'exemple utilisaient une sémaphore pour s'assurer de l'exclusivité de l'accès en écriture ou en lecture. Mais bon si c'est superflue, j'en ai pour 10 secondes à virer le code correspondant.
Je connaissais pas les message queues, je viens de regarder vite fait, exact ca aurait pu faire l'affaire, mais les pipes tout autant. Par contre le code serait tout de même un peu plus lourd qu'avec les pipes. Le seul avantage c'est que n'importe quel processus peut se connecter à la queue s'il a connaissance de la clé correspondante, mais vu que le pipe est crée dans le premier processus avant tout fork, cela ne me sert à rien.
Bah écoute... si t'as une suggestion au niveau de l'algo je suis preneur J'y ai pas mal reflechis, à part envoyer les descripteurs de fichiers au processus voulu, ou passer aux pthreads pour la gestion des connexions reseaux au niveau du port d'administration... je vois pas |
Taz bisounours-codeur | moi aussi j'ai quiché, je cherchais moving/exchanging/sending
|
Taz bisounours-codeur | le noyau il est gentil, mais si ton écriture est interrompue, ou incomplète, ça risque de pas faire du joli joli ... pourquoi ne pas faire des pipes séparés tout simplement ? |
Publicité | Posté le 02-10-2007 à 13:20:41 |
Taz bisounours-codeur | je comprends pas bien. le pipe est entre qui et qui ? entre parent et fils ? |
franceso |
--------------- TriScale innov |
sigmatador | Exact, cette solution bien que plus gourmande, aurait été par contre très propre au niveau du design.
Message cité 1 fois Message édité par sigmatador le 02-10-2007 à 17:19:51 |
franceso |
Je vois mal comment tu pourrais te passer du signal. Par contre, tu peux peut-être remplacer le sendmsg par un segment de mémoire partagée, mais je sais pas si ça servirait à grand chose...
--------------- TriScale innov |
Sve@r |
Message cité 1 fois Message édité par Sve@r le 02-10-2007 à 18:17:31 --------------- Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche. |
sigmatador |
Message édité par sigmatador le 04-10-2007 à 12:53:42 |
franceso |
+1
Euh, là je comprends pas trop ce que tu veux dire : effectivement, si tu supposes que chacune des écritures est atomiques, tu n'as pas besoin de synchroniser les différents écrivains. Par contre, dans le cas des écritures incomplètes, même avec un marqueur de fin de message je ne vois pas comment tu te passes d'une synchronisation explicite des écrivains.
--------------- TriScale innov |
Sve@r |
Message cité 1 fois Message édité par Sve@r le 03-10-2007 à 16:40:44 --------------- Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche. |
franceso |
Donc pour peu que tu utilises directement l'appel système "write", le noyau te garantit que ton écriture dans le tuyau sera forcément atomique ? Quelle que soit la quantité d'informations que tu envoies ?
Donc finalement, ça dépend bien de la taille des données. Message cité 2 fois Message édité par franceso le 03-10-2007 à 17:04:05 --------------- TriScale innov |
Sve@r |
--------------- Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche. |
franceso |
Oui, c'est bien 4ko maintenant :
--------------- TriScale innov |
Taz bisounours-codeur | Euh il me semble que sur un 2.6 récent, Linus a amélioré la triperie et que derrière c'est un FIFO 12 pages. |
franceso |
Les 4096bytes c'est sur un 2.6.12 (donc pas trop récent...)
--------------- TriScale innov |
Taz bisounours-codeur |
Toutes façons, c'est peut-être un peu fragile de s'appuyer là dessus, si la taille de message augmente, ça va commencer à poser problème. |
sigmatador |
Message édité par sigmatador le 04-10-2007 à 12:33:44 |
sigmatador |
Message édité par sigmatador le 04-10-2007 à 12:34:01 |
sigmatador | Par contre j'ai un autre problème maintenant ^^.
Message édité par sigmatador le 04-10-2007 à 12:45:31 |
franceso | Je ne pense pas que l'atomicité soir valable aussi pour les sockets. Dans la norme, c'est précisé uniquement pour les FIFO et les pipes. Mais Sve@r a l'air beaucoup plus au courant que moi de ce genre de détails.
--------------- TriScale innov |
sigmatador | Déjà, ce n'est pas le processus qui accepte les connexions qui s'occupe de lire dans le pipe. C'est pour ca que j'ai eu besoin d'envoyer le descripteur du socket au processus qui lit le pipe.
Message édité par sigmatador le 04-10-2007 à 15:23:51 |
sigmatador |
Message cité 1 fois Message édité par sigmatador le 04-10-2007 à 15:24:41 |
franceso | merci pour les explications, c'est beaucoup plus clair
Perso, je choisirais cette deuxième solution.
Tu as essayé de voir ce qu'il se passe au niveau du processus "admins" (celui qui accepte la connection) ? Est-ce qu'un write chez lui détecte la fermeture de la socket ou pas ? Ce test devrait permettre de déterminer si le problème vient de la transmission du fd ou d'ailleurs.
--------------- TriScale innov |
sigmatador |
Oui le processus admin detecte sans problème la fermeture, un recv ou un send retourne -1. J'ai même testé avec 2 processus admins concurrent sur le même socket, si le peer ferme la connexion, les 2 le detect, si l'un des 2 le ferme, l'autre le detecte aussi. Et dans tous les cas, le processus journal est dans les choux quelque soit celui qui ferme le socket. |
Sve@r |
Message édité par Sve@r le 04-10-2007 à 17:07:37 --------------- Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche. |
sigmatador | Bon je remonte le post car j'ai un nouveau problème avec mon appli (aucun rapport avec l'ancien problème si ce n'est que cela relève aussi du parallélisme sous linux)
Message cité 2 fois Message édité par sigmatador le 22-10-2007 à 18:04:49 |
sigmatador | 3- La solution que je voudrais implémenter --> ma préférée mais je sais pas si c'est fesable ^^
Message édité par sigmatador le 22-10-2007 à 18:14:03 |
franceso |
Question bête mais je la pose quand même au cas où : tu peux pas stocker directement le pattern en mémoire partagée ? A charge au processus tâche de faire son pcre_compile...
--------------- TriScale innov |
sigmatador |
Message édité par sigmatador le 22-10-2007 à 18:53:30 |
Publicité | Posté le |
Page : 1 2 Page Précédente |
Sujets relatifs | |
---|---|
Ecrire dans un cube AnalysisServices2005 | Ecrire dans un argument en Javascript ? |
[WSH Scripting] écrire dans fichier texte depuis fichier excel | entrer du texte au clavier sans l'afficher, sous bash. |
Ecrire un fichier wav avec fmod ex | [java] algorithme du simplexe |
Algorithme Monte Carlo | directive php pour ecrire variable dans chaine sans guillemets |
défi algorithme date | Problème pour écrire dans une table! |
Plus de sujets relatifs à : Algorithme parallélisé: Je n'arrive pas à l'écrire avec fork() |