Discussion :

[chezjm]

Apparement, mais j'espère fort me tromper, fork() n'existe pas sous Windows et c'est une fois de plus fort dommage!
G trouvé deux fonctions "Windows" : CreateProcess et CreateThread.
Le pb est qu'elles ne m'ont pas l'air de faire exactement comme fork(), c'est à dire une copie du process parent en conservant les variables et s'exécutant à partir de l'endroit d'appel.

Si vous pouviez me contredire sur l'existence de fork, ou me dire quoi utilisez pour m'en rapprochez, je vous en serait reconnaissant.

JM

[gRRosminet]

hé bien malheureusement, il ne va pas être possible de te contredire
En effet, sous windows tu n'as que les deux fonctions que tu site et qui comme tu l'as très bien remarqué ne font pas une copie du process parent mais exécute un exe dans le cas de CreateProcess ou une fonction pour CreateThread.
Cependant, on peut se rendre compte que ce qui se fait avec un fork, pet souvent se réaliser avec unthread alors tu devrais pouvoir trouver un moyen de contourner les difficultés

[Miko]

Jusqu'à présent j'ai toujours utilisé CreateProcess pour lancer une autre application et CreateThread pour gérer plusieurs tâches en lieu et place d'un fork.

A mon avis il faut revoir toute l'architecture de ton logiciel et l'adapter à Windows sachant qu'il y a pas mal de différences entre fork et CreateThread.

fork duplique la zone data pour chaque process alors que CreateThread partage l'ensemble des données entre les différents thread rattaché à ton process.

J'ai entendu dire que sous NT il y avait un kit de développement spécial pour porter facilement des applis UNIX. Si quelqu'un pouvait rappeler le nom de ce produit ça faciliterait la vie à JM.

Une petit idée quand même si tu dois gérer un code multiplateforme (sinon oublie tout ça et adapte toi aux paricularités windows) :
- mettre toutes les variables globales dans une structure (s_global par ex)
- déclarer un tableau s_global g[1] si UNIX et g[2] si Windows,
- si unix accéder à g[0] quel que soit le process (père ou fils),
- si windows copier g[0] dans g[1] (pour simuler la duplication des datas) et accéder à g[0] dans le thread principal et g[1] pour le thread annexe,
- augmenter la taille du tableau si plus de 2 threads.

J'espère que ca pourra t'aider.

[chezjm]

Bon, et est-ce qu'il y a moyen de partager un sémaphore mutex entre plusieurs threads crées par CreateThread?
C à peu près tout ce que j'attends de mes process fils.

[Tifauv']

J'ai entendu dire que sous NT il y avait un kit de développement spécial pour porter facilement des applis UNIX. Si quelqu'un pouvait rappeler le nom de ce produit ça faciliterait la vie à JM.

Ca ne serait pas Cygwin ?

[Miko]

Ca ne serait pas Cygwin ?

Non du tout, c'est un produit purement de chez M$.

Et pour répondre à JM, voici le prototype de CreateMutex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
HANDLE CreateMutex(
 
    LPSECURITY_ATTRIBUTES  lpMutexAttributes,	// address of security attributes 
    BOOL  bInitialOwner,	// flag for initial ownership 
    LPCTSTR  lpName 	// address of mutex-object name  
   );

Il suffit d'initialiser lpName à la même valeur.

[fd]

Sous NT 4 il existe un "sous-systeme" a la norme Posix (1.2 je crois (sans garantie).

C'est a dire qu'une appli ne faisant appel QU'A des fnc posix pourra etre recompilé avec un compilo style gcc et tourner sur nt4.

Je ne sais pas si 2000 supporte ce sous-systeme

[chezjm]

Il suffit d'initialiser lpName à la même valeur.

A la même valeur que quoi?

[Miko]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
hMutex = CreateMutex(NULL, FALSE, "MonMutex");
WaitForSingleObject(hMutex, INFINITE);

Et ce dans chacun des threads qui ont besoin du mutex.

Il est possible d'utiliser un timeout exprimé en millisec à la place de INFINITE.