Bonjour,

je réalise une plateforme qui applique des traitements à des fichiers.
Pour faire simple, lors du lancement, on récupère le répertoire des fichiers à traiter qui sera parcouru avec un walk, un gestionnaire prend le fichier courant et lui applique les traitements sélectionnés, pour finir on stocke les résultats.

Pour l'instant le traitement est sériel, pour un répertoire de 5 fichiers, A->E et si on applique les traitements 2,5 et 8 on aura :
traitement 2 sur A, tr5 sur A, tr8 sur A puis tr2 sur B, ... jusqu'à tr8 sur E

Dans l'optique de rendre cette plateforme plus rapide, on m'a demandé de faire une version parallèle.

Après avoir regardé des tutos, de la doc (thread, threading, queue, multiprocessing, ...), je voyais les choses comme ça. Au fur et à mesure du parcours du répertoire cible, le gestionnaire va remplir une queue (fifo du coup) avec les traitements sur les fichiers sous forme de tâches. Quand la queue est pleine, on attend. Et pendant ce temps on a les différents threads qui font les tâches en parallèle. Alors déjà, est-ce que cette démarche est correcte ?

Les traitements sont sous forme de classes, qui sont instanciées à la sélection et qui ont entre autres une fonction action(path).
Le problème que je rencontre est que, si j'ai bien compris, au moment de la création du thread, threading.Thread(), il faut lui fournir dans target un objet exécutable. Dans mon cas je devrais lui passer la fonction action() du traitement, ce qui m'embête puisque cela contraint un thread à ne travailler qu'avec un type de traitement (ou alors j'ai mal compris).

Ma question est donc : est-ce qu'il y a un moyen d'attribuer différentes actions à un thread alternativement comme ce que je voudrais faire ?

Sinon, peut-être qu'il faut placer l'action parallèle à un autre endroit ?

Merci