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

[anthoine.bourgeois]

Rebonjour,


> Message du 10/10/07 17:55
> De : "geoffroy weisenhorn" <geoffroy.weisenhorn at gmail.com>
> A : "SOS mailing-list" <sos at the-doors.enix.org>
> Copie à : 
> Objet : Re: [SOS] Article 10 -- système de fichiers FAT
> 
> Cepandant un bug plus génant survient à la terminaison de fstestfat,
> SOS backtrace et dit : "No kernel thread ready ?!" dans la fonction
> sos_reschedule de sched.c.
> je sais pas du tout quelle sont les conditions qui on amené l'ordonnanceur
> dans cet état et surtout comment l'éviter... je continue à recherche ..

Ce week-end j'ai regardé le problème. Je vous fais part de mes recherche
et vous mets à contribution pour trouver une solution car je n'en vois
aucune qui soit correct.

L'appel système exit() fait un appel à sos_thread_delete().
sos_thread_delete appelle l'ordonnanceur pour changer de thread.
Le thread idle est élu puisqu'il est seul il n'y a plus d'autre 
thread dans les files de l'ordonnanceur à ce moment.
La destruction du thread s'execute donc avec le thread idle.
La destruction du thread entraine la destruction du processus
qui contenait ce thread.
Le processus contenait des fichiers ouverts.
Ces fichiers sont fermé un à un.
C'est ici que le problème survient :
L'écriture sur disque provoque bloquage sur des sémaphores (ide.c:605)
donc le thread idle rentre dans une waitqueue et l'ordonnanceur
et rappelé pour l'election un nouveau thread.
Comme le thread idle était le dernier on tombe sur le problème
décrit plus haut.

Je ne vous pas de solution propre.
-On ne peut pas syncroniser les fichiers avant la suppression
du thread.
-On ne peut pas supprimer les sémaphores de la procédure
d'écriture disque.
-On ne peut pas empécher l'ordonnanceur d'élire le thread
idle pour écrire sur le disque.

Peut-on refaire passer le thread bloqué dans une waitqueue
dans l'état "pret" s'il est le seul disponible?

Dans la pratique ca marche mais je ne trouve pas ca propre.

Qu'en pensez-vous?

Anthoine