CreateFile et FILE_FLAG_OVERLAPPED

Bonjour,
après avoir fais quelques recherche et pas trouvé de réponse je viens poster ici.

Mon but est de créer une image .tif
j'utilise la fonction CreateFile et comme argument le FILE_FLAG_OVERLAPPED

D'après les exemples trouvé sur le net cette arguement est utilisé uniquement avec les Port Com. Est ce qu'il est possible que je l'utilise dans mon cas pour créer mon .tif ?

J'ai bien sur essayer avec d'autre arguments à la place de FILE_FLAG_OVERLAPPED comme FILE_ATTRIBUTE_NORMAL
mais le problème est qu'il me faut une vitesse d'écriture sur disque importante que ,j'espère, me fournira le FILE_FLAG_OVERLAPPED.

Il est dit aussi qu'une structure de type OVERLAPPED doit être initialisé mais je n'ai pas trouvé d'exemple ou d'utilisation autre qu'avec les port Com

Code:

---

1 2	HANDLE hFile = CreateFile(name, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_FLAG_OVERLAPPED , NULL); OVERLAPPED ovl;

---

Merci d'avance pour tout aide apporté.

Salut,
Bien que ne l'ayant jamais essayé, je dirais que rien ne l'interdit pour un fichier. Il en résultera que les lectures et les écritures seront asynchrones (la fonction retournera même si l'écriture n'est pas terminée).
Par contre, je ne suis pas sûr que tu puisses positionner la vitesse d'écriture du disque.

Merci pour le réponse rapide.

Il me reste tout de même un problème.

Code:

---

bool ok=WriteFile(hFile, _TiffHeader, sizeof(TifHead), &iWrittentmp, NULL);

---

Lorsque mon create file à FILE_FLAG_OVERLAPPED le write file me retourne false et rien n'est écrit dans mon fichier.

Je ne cherche pas à positionner la vitesse d'écriture c'est juste que je pense que le mode asychrone soit le plus rapide car justement on ne bloque pas dedans la fonction le temps de l'écriture.

Mais je n'ai pas vraiment compris ce que je devais faire avec la structure OVERLAPPED qui est utilisé avec ce flag

Effectivement, si tu positionnes le flag FILE_FLAG_OVERLAPPED, tu dois fournir une instance de OVERLAPPED à la fonction WriteFile.
2 solutions:
1/ Soit tu as réellement besoin que les écritures soient asynchrones : alors il faut que tu gère une telle variable avec la synchronisation. Mais là, c'est un peu plus costaud. Il faut passer une variable de la structure dont la durée de vie est au moins égale à la durée de l'opération. Tu peux te synchroniser sur l'écriture avec GetOverlappedResult (mais pourquoi être asynchrone alors?). Et, je ne sais pas comment sont gérés les accès concurrents (plusieurs écritures les unes à la suite des autres sans attendre la fin de la précédente). Il doit certainement il y avoir un cache, donc à gérer un échec à demande d'écriture dès que le cache est plein... Probablement, qu'il te faudra prévoir un mécanisme de type multithread ou traitement dans OnIdle. Donc la question est : as-tu vraiment besoin d'être asynchrone ?

2/ Soit tu n'as pas vraiment besoin d'être asynchrone : passes-toi du flag overlapped.

Je n'ai pas forcément besoin que ce soit asynchrone mais que ce soit rapide (et je pensais que le FILE_FLAG_OVERLAPPED m'apporterais cette rapidité)

j'ai déja essayé avec le flag FILE_ATTRIBUTE_NORMAL qui lui est beaucoup trop lent et avec FILE_FLAG_NO_BUFFERING qui me pose des problèmes en modifiant mon entête .tif (replace des WORD par des DWORD ce qui rend mon image non valide)

FILE_FLAG_OVERLAPPED ne rendra pas les accès + rapides. Ils sont tout simplement asynchrones. Cela veut dire que ta fonction retourne même si l'écriture n'est pas terminée.
FILE_FLAG_NO_BUFFERING : je ne me souvient pas l'avoir utilisé. Désolé...

Une autre solution pour rendre ton appli disponible pendant l'écriture est de déléguée celle-ci à un thread qui serait chargé de faire cette écriture.

Néanmoins, tu peux explorer l'écriture asynchrone, mais en toute franchise, je ne l'ai fait qu'il y a longtemps et pour du RS232. Donc, je ne sais pas quels peuvent être les soucis que tu vas rencontrer. A mon avis, il faut gérer l'overlaped, l'écriture partielle ou échec (lorsque les buffers sont pleins) et voir comment cela se comporte lorsque tu demandes plusieurs écritures les unes à la suite des autres. Un défrichage intéressant mais laborieux ;)

Merci 3D archi je vais me replonger dans le overlapped voir si j'arrive a en faire quelque chose.

Pour le thread a part c'est en test mais le problème reste le même, si je n'arrive pas à écrire assez vite je vais me retrouver avec les quantitées monstrueuses d'image dans mes buffers.

La structure OVERLAPPED n'est pas trop difficile à utiliser: TU as juste à remplir les champs Offset, OffsetHigh et hEvent.
L'événement passé dans la structure sera signalé à la fin de l'écriture...

Pas de problème :D

Je suis entrain de tester en initialisant la structure overlapped, d'après ce que j'ai lu et ce que tu me dis je ne m'occupe donc pas de tous ce qui est internal et pointeur qui sont remplis par la fonction elle même.

le hevent n'est pas vraiment utile non plus dans mon cas car je n'ai pas (enfin je pense) besoin d'avoir d'info sur la fin d'écriture.

Je vais tester tous sa avec vos infos et je vous tiens au courant.

merci et bonne continuation

Problème résolu (je mets le bout de code en rapport avec le sujet)

Code:

---

1 2 3 4 5 6 7 8 9

OVERLAPPED _ovl; ZeroMemory( &_ovl , sizeof( OVERLAPPED )) ; _ovl.Offset = 0xFFFFFFFF; _ovl.OffsetHigh = 0xFFFFFFFF; _ovl.hEvent = NULL; HANDLE hFile = CreateFile(name, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_FLAG_OVERLAPPED , NULL); WriteFile(hFile, DATA, SIZE, &iWritten, &_ovl);

---

J'avais une mauvaise initialisation de mon offset et de OffsetHigh de la structure OVERLAPPED.

Le flag FILE_FLAG_OVERLAPPED peut donc bien être utilisé ailleur que avec les ports Com.

Merci a tous pour l'aide et bonne continuation

Attention, si tu sort de ta fonction avant que l'écriture se termine, _ovl est détruit, et le comportement de WriteFile devient indéterminé !

oui mais mon _ovl est déclaré en global donc pas de risque la dessus.

Pas de risque d'écrasement si tu refais une écriture alors que la précédente n'est pas terminée? Là, j'avoue que je ne sais pas comment l'API est sensée réagir.

oui je vais regarder un peu la dessus car je me retrouve avec des images vides (qui viennent peut être de l'écrasement).

Sinon tester avec le flag FILE_FLAG_NO_BUFFERING en plus de celui FILE_FLAG_OVERLAPPED et dans ce cas là toutes les images sont conformes (mais je ne suis plus sur que l'overlapped soit encore utilisé dans ce cas :?)

Sa marche mais reste à faire quelques tests.

merci encore pour les réponses vraiment rapides.

Il y a un moyen simple d'éviter des écritures simultanées: Utiliser le hEvent pour s'assurer qu'une écriture est finie avant d'en démarrer une autre.

La contrainte sur la durée de vie de la structure OVERLAPPED t'interdit toute politique de "fire and forget"...

Citation:

---

Envoyé par kill4m

Sinon tester avec le flag FILE_FLAG_NO_BUFFERING en plus de celui FILE_FLAG_OVERLAPPED et dans ce cas là toutes les images sont conformes (mais je ne suis plus sur que l'overlapped soit encore utilisé dans ce cas :?)

---

Intuitivement, je dirais que les deux flags sont indépendants. NO_BUFFERING va forcer l'écriture immédiate, mais si elle prend plus de temps avant que survienne ton appel suivant, ça ne devrait rien changer...

Citation:

---

Envoyé par Médinoc

La contrainte sur la durée de vie de la structure OVERLAPPED t'interdit toute politique de "fire and forget"...

---

Même si on utilise une structure OVERLAPPED différente à chaque fois? (puis quelque part une boucle avec GetOverlappedResult pour voir celles qui se sont terminées) ?

Le problème d'utiliser le hEvent c'est que faire waitforsingleobject est bloquant et c'est ce que je ne veux pas.

Je vais tester avec un tableau de structure overlapped (en global) et en changer à chaque passage pour éviter les écrasements pendant l'écriture (et voir si sa vient de la).

Mais dans ce cas, on doit mémoriser chaque structure, donc ça n'est plus du "fire and forget".