SetCurrentDirectory dans une application multithread

Question

Je comprends que SetCurrentDirectory ne doit pas être utilisé dans une application multithread puisque le répertoire courant est partagé entre tous les threads du processus.

Quelle est la meilleure approche pour définir le répertoire dans cet esprit. Il est généralement possible d'éviter de définir le répertoire en incluant le chemin d'accès complet lors de l'ouverture des fichiers au lieu d'y accéder d'abord avec SetCurrentDirectory, mais est-ce la seule solution?

Answer 1

J'ai déjà rencontré ce problème.

Tout objet nécessitant le concept d'un répertoire courant pour prendre en charge les chemins relatifs ou la recherche (par exemple un outil de construction) possède une propriété membre qu'il maintient avec son chemin "actuel", puis crée le chemin complet pour ouvrir/créer/chercher.

La valeur initiale de CurrentPath peut être extraite une fois pendant la phase de chargement de l'application, par ex. main(), WinMain(), DllInit(), etc. via GetCurrentDirectory et stockées dans un global. Après cela, la version Win32 est ignorée.

La structure OPENFILENAME dispose d'un membre de répertoire initial. Les boîtes de dialogue d'ouverture/de sauvegarde de fichiers n'ont donc pas besoin d'utiliser le répertoire actuel Win32.

Answer 2

Chaque processus a un seul répertoire courant, donc si vous voulez que chaque thread de votre processus utilise un répertoire courant différent, je pense que vous devriez spécifier le chemin complet dans chacun.

Answer 3

Un conseil pour utiliser les chemins complets dans les chemins généraux et locaux uniquement en tant qu'exception (et très soigneusement), si nécessaire. C'est à dire. la boîte de dialogue OpenFile peut ou non changer le répertoire courant (en fonction des attributs), etc. L'utilisation de noms de fichiers ou de chemins locaux est une cause potentielle de problème. Par mon expérience, les chemins complets ne ralentissent pas l'accès aux fichiers de façon significative. J'ai écrit une application qui ouvre des milliers de fichiers chaque minute et écrit des données triées vers d'autres milliers de fichiers - tous utilisant des chemins complets et le tout sur un lecteur réseau monté sur Windows. Le goulot d'étranglement là fermait les fichiers. Ne pas les ouvrir.