C++ - Tester l'accessibilité à un fichier sur le réseau en mode asynchrone

Bonjour,

Je développe actuellement une application qui va venir interagir avec bon nombre de fichiers, dont certains situés sur un réseau.

Mon problème c’est que je ne trouve pas de solution propre pour tester l’accessibilité d’un fichier sur le réseau en mode asynchrone. Toutes les méthodes que j’ai essayé sont synchrones et donc bloquantes (avec des temps de traitement variable à chaque fois ).

Je sais que le principal problème est bien évidemment la mise en place du réseau ou je travaille, mais malheureusement je ne peux pas y remédier :(.

J’ai déjà testé plusieurs choses :

1) IOCP avec la méthode ReadFile

Le problème avec cette méthode, c’est que pour utiliser ReadFile, il faut au préalable créer un handle de fichier avec la méthode CreateFile (qui elle n’est pas asynchrone :() Donc pour un fichier non accessible, la méthode CreateFile va mouliner dans le vide un certain nombre de temps.

2) std::filesystem

J’ai essayé plusieurs méthodes avec la bibliothèque de gestion de fichiers, dont la méthode Exists, mais une nouvelle fois, l’opération est encore synchrone.

3) std::future, std::promise, std::async

J’ai aussi essayé plusieurs méthodes de la bibliothèque de gestion d’opérations asynchrones, mais une nouvelle fois, les résultats n’ont pas été concluants !

Conclusion :

Au vu de tous ces échecs, j’ai vraiment l’impression que ce genre de cas (une demande d’accès vers un fichier sur le réseau) n’est pas pris en compte ou alors n’est pas censé arriver, ce qui expliquerait le manque de solution pour réaliser cela ?

Deuxième conclusion :

Je suis totalement à côté de la plaque, et il existe bien une solution !

N’hésitez pas à proposer votre aide !

Merci d’avance !

Salut !

Merci de ta réponse

Avec les threads séparés "ça fonctionne", mais le problème c’est que le thread tourne aussi longtemps que la méthode synchrone est en attente de réponse.

Au début, je pensais juste envelopper la tentative d’ouverture du fichier dans un thread avec un timeout en utilisant std::future::wait_for. Le problème, c’est que le thread ne peut pas être kill proprement vu que l’opération à l’intérieur est bloquante. Du coup, le wait_for était totalement ignoré …

Ensuite je pensais créer autant de threads que de fichiers à analyser, et récupérer les résultats au bout d’un certain temps. Et laisser les thread encore en "running" se terminer tout seul.

Mais ça pose deux problèmes :

• Si l’utilisateur cherche à quitter le logiciel, alors que des threads sont encore en mode "running" ? Ca va bloquer la fermeture …

• Je ne suis pas sur que créer un thread par fichier soit vraiment une bonne idée, c’est une opération coûteuse…

Oui j’ai oublié de préciser, mais je cherche une solution principalement Windows only.

C’est noté merci, je vais regarder du côté de boost::asio

Si l’utilisateur cherche à quitter le logiciel, alors que des threads sont encore en mode "running" ? Ca va bloquer la fermeture …

Je ne pense pas que ce soit un gros problème si le programme continue à tourner quelques secondes de plus après que la fenêtre ait été fermée, à condition bien sûr que ce soit vraiment quelques secondes seulement et non pas des minutes ou pire.

Ce qui compte c’est que la fenêtre se ferme tout de suite quand l’utilisateur clique sur la croix ou Alt+F4. Le reste il ne le remarquera même pas.

Dans le pire des cas, il existe un truc imparable: exit(0). On n’appelle pas ça quitter une application dans les règles de l’art, mais ça marche très bien.

Je ne suis pas sur que créer un thread par fichier soit vraiment une bonne idée, c’est une opération coûteuse…

Si tu ouvres 100 fichiers en même temps on peut discuter. Mais pour 3, 5 ou même 10, franchement, c’est peanuts. Il n’est pas rare d’avoir des applications démarrant plusieurs dizaines de threads.

Si tu charges des fichiers en arrière-plan tout au long du fonctionnement de l’application, tu peux éventuellement mettre en place un système de pool pour réutiliser les threads créés au lieu d’en créer des nouveaux à chaque fois.