[SOS] Article 10 -- système de fichiers FAT

[anthoine.bourgeois]

Salut,


> Message du 28/11/07 11:00
> De : "geoffroy weisenhorn" <geoffroy.weisenhorn at gmail.com>
> A : "anthoine.bourgeois" <anthoine.bourgeois at wanadoo.fr>, "SOS mailing-list" <sos at the-doors.enix.org>
> Copie à : 
> Objet : Re: [SOS] Article 10 -- système de fichiers FAT
> 
> Bonjour ,
> 
> J'aurais une question à propos de la solution proposé sur la gestion
> de cette famine de thread:
> j'avais eu un peu près la même idée dans le sens où notre problème
> apparaît à la fermeture de fichiers qui doivent être écrit/réécrit sur
> le périphérique de bloc pourquoi ne pas laisser faire ce travail de
> synchronisation au thread bdflush au lieu
> d'avoir un nouveau thread noyau ? seulement j'ai pas réussi à trouver
> dans le code
> où les opérations d'écriture sont lancés suite à la fermeture de
> fichier, mais finalement c'est peut-être pas une solution aussi simple
> que la solution proposée et que d'autres problèmes risque
> d'apparaître.

On a pas de thread bdflush dans SOS mais c'est une bonne idée.
Au lieu d'avoir un thread fossoyeur qui s'occupe des destructions de
threads, on peut avoir un thread bdflush qui s'occupe des écritures
disque (qui est la cause de notre problème de famine).
On améliore ainsi la granularité.
L'écriture des fichiers se fait dans process.c:423.
C'est une idée a creuser.

> d'ailleurs j'ai un message de gcc très bizarre en utilisant le patch:
> sos/thread.c: In function 'sos_thread_exit':
> sos/thread.c:469: warning: 'noreturn' function does return

J'ai pas essayé le patch, je l'ai juste lu.
void sos_thread_exit(void) __attribute__((noreturn));
Il faut retirer le __attribute__((noreturn)) dans thread.h
car maintenant la fonction retour puisque le 
sos_cpu_context_exit_to a été supprimé.

> 
> Sinon au sujet du compromis réactivité/mémoire j'ai pas bien compris
> où se situe le problème ? ce problème apparaît -il dans le cas de
> nombreuses terminaisons de threads et de ressources mémoire limitée,
> la suppression des ressources mémoire n'est pas immédiate dans le cas
> où un thread de haute priorité récupère la main, c'est ça ?

oui, c'est ca. Si l'on a 100 threads qui se termine et toujours un
thread plus prioritaire le thread fossoyeur alors on aura une liste de
100 structures en mémoire qui attendra d'etre supprimé.

Anthoine