Multithreaded Application Tutorial/fr: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		# Vue d'ensemble
2	2
3	3		Cette page essayera d'expliquer comment écrire et corriger une application multi-tâches avec Free Pascal et Lazarus.
4	4
5	5		Une application multi-tâches est celle qui crée deux tâches d'execution ou plus en même temps.
6	6
7	7		Si vous êtes nouveau dans le multi-tâches, veuillez lire le paragraphe "Avez vous besoin du multi-tâches ?" pour découvrir si vous en avez vraiment besoin (Vous pouvez vous éviter beaucoup de maux de tête).
8	8
9	9		Une des tâches (threads) s'appelle la tâche principale . La tâche principale est celle qui est créé par le système d'exploitation lorsque notre application démarre. La tâche principale doit être la seule tâche qui met à jour les composants qui interfèrent avec l'utilisateur (autrement , l'application risque de planter ).
10	10
11	11		L'idée principale est que l'application peut faire quelques traitements en arrière-plan (dans une deuxième tâche) tandis que l'utilisateur peut continuer à travailler (en utilisant la tâche principale).
12	12
13	13		L'utilisation des tâches permet aussi d'avoir une application qui répond mieux. Si vous créez une application, et que, quand l'utilisateur appuie sur un bouton, l'application commence le traitement (un gros travail )... pendant le traitement , L'écran arrête de répondre, et donne à l'utilisateur la sensation que l'application est plantée, ce n'est pas très agréable. Si le gros travail fonctionne dans une deuxième tâche, l'application continue à répondre (presque ) comme si elle était en idle. Dans ce cas, il est préférable avant de commencer la tâche, de neutraliser les boutons de la fiche pour éviter que l'utilisateur ne démarre plus d'une tâche de travail .
14	14
15	15		Une autre utilisation , est de créer une application serveur qui est capable de répondre à beaucoup de clients en même temps .
16	16
17	17		# Avez vous besoin du multi-tâche?
18	18
19	19		Si vous êtes un novice dans le multi-tâche et que vous souhaitez simplement rendre votre application plus nerveuse lorsqu'elle a une grande charge de travail, alors le multi-tâche n'est peut-être pas ce que vous recherchez. Les applications multi-tâches sont toujours plus difficile et à debogguer, elles sont souvent beaucoup plus complexes. Dans beaucoup de cas vous n'avez pas besoin du multi-tâche, une seule tâche est suffisante. Si vous pouvez fractionner les longues corvées de travail en plusieurs petits morceaux, utilisez plutôt Application.ProcessMessages, cette méthode laisse la LCL traiter tous les messages en attente et en retour. L'idée est de traiter une partie du travail, puis d'appeller Application.ProcessMessages pour voir si l'utilisateur abandonne ou clique quelque part, ou d'actualiser un indicateur de progression, et ensuite de continuer avec la partie suivante du travail, appeler Application.ProcessMessages et ainsi de suite. Pensez également, lors de l'exécution d'une application externe (à la manière d'un script) de laisser du temps à l'éventuel système tiers de digérer la commande en mettant votre application en pause à l'aide de la commande sleep(miliseconds) de l'unité sysutils.
20	20
21	21		Par exemple : Lecture d'un grand fichier et son traitement . Voir examples/multithreading/singlethreadingexample1.lpi.
22	22
23	23		Le multi-tâche est seulement nécessaire pour
24	24
25	25		- le blocage des handles, comme les communications de réseau
26	26		- l'utilisation de plusieurs processeurs à la fois
27	27		- les algorithmes et les appels de bibliothèque, qui ne peuvent pas être fractionné dans de petites pièces.
28	28
29	29		# La classe TThread
30	30
31	31		L'exemple suivant se trouve dans le répertoire examples/multithreading/.
32	32
33	33		Pour créer une application multi-tâches, la manière la plus simple est d'utiliser la classe TThread.
34	34
35	35		Cette classe permet la création d'une tâche supplémentaire (à côté de la tâche principale) de manière simple.
36	36
37	37		Normalement, il suffit de surcharger 2 méthodes: le constructeur Create, et la méthode Execute.
38	38
39	39		Dans le constructeur, vous préparez la tâche à s'exécuter, vous fixerez les valeurs initiales des variables ou des propriétés que vous souhaitez. Le constructeur original de TThread exige un paramètre appelé Suspended. Comme vous pourriez le prévoir, fixer Suspended = True empêchera la tâche de commencer automatiquement après sa création . Si Suspended = False, la tâche commencera à fonctionner juste après sa création, si Suspended = True elle ne fonctionnera qu'après l'appel de la méthode Start.
40	40
41	41		> Note: La méthode Resume est [obsolète depuis FPC 2.4.4](http://wiki.freepascal.org/User_Changes_2.4.4#TThread.Suspend_and_TThread.Resume_have_been_deprecated). Elle est remplacée par Start.
42	42
43	43		A partir de FPC version 2.0.1 et au delà, TThread.Create a également un paramètre implicite de taille de la pile. Vous pouvez maintenant changer la taille de la pile par défaut pour chaque tâche que vous créez (si vous en avez besoin). Les appels de procedure récursifs dans une tâche sont un bon exemple. Si vous n'indiquez pas le paramètre de la taille de la pile, la taille de pile de l'OS par défaut est employée.
44	44
45	45		Dans la méthode surchargée Execute vous écrivez le code qui fonctionnera dans la tâche.
46	46
47	47		La classe TThread a une propriété importante : Terminated : boolean;
48	48
49	49		Si la tâche est une boucle (ce qui est habituel), la boucle devra être quittée quand Terminated passera à True (sa valeur est False par défaut). Ainsi dans chaque cycle, la tâche doit tester si Terminated vaut True, et si c'est le cas, doit sortir de la méthode Execute aussi rapidement que possible (après tout nettoyage nécessaire).
50	50
51	51		Gardez aussi à l'esprit que la méthode Terminate ne fait rien par défaut: la méthode Execute doit explicitement faire le nécessaire pour stopper son travail.
52	52
53	53		Comme nous l'avons expliqué plus tôt, la tâche ne devra pas interagir avec les composants visuels. Pour interagir avec l'utilisateur elle devra le faire dans la tâche principale. Pour faire cela, il faut utiliser la méthode Synchronize de la classe TThread. Synchronize prend en paramètre une méthode (qui, elle, ne prend aucun paramètre) comme argument. Quand vous appelez cette méthode au moyen de Synchronize(@MyMethod), l'execution de la tâche sera mis en pause, le code de MyMethod s'exécutera dans la tâche principale, et ensuite l'exécution de la tâche reprendra. Le fonctionnement exact de Synchronize dépend de la plate-forme, mais fondamentalement elle fait ceci: Elle se signale par un message sur la file d'attente de message principale et va dormir. Par la suite, lorsque la tâche principale traite ce message, elle appelle MyMethod. De cette façon MyMethod est appelé hors contexte, ce qui signifie pas pendant un évènement de déplacement de souris ou pendant un événement de peinture, mais après. Dès que la tâche principale a exécuté MyMethod, elle réveille la tâche en sommeil et exécute le message suivant. La tâche continue alors.
54	54
55	55		Il y a une autre propriété importante de la classe TThread: FreeOnTerminate. Si cette propriété est true, l'objet tâche est automatiquement libéré quand l'execution de la tâche (méthode .Execute) s'arrête, sinon l'application devra le libérer manuellement.
56	56
57	57		Exemple :
58	58
59	59		``` pascal
60	60		Type
61	61		TMyThread = class(TThread)
62	62		private
63	63		fStatusText : string;
64	64		procedure ShowStatus;
65	65		protected
66	66		procedure Execute; override;
67	67		public
68	68		Constructor Create(CreateSuspended : boolean);
69	69		end;
70	70		```
71	71
72	72		``` pascal
73	73		constructor TMyThread.Create(CreateSuspended : boolean);
74	74		begin
75	75		FreeOnTerminate := True;
76	76		inherited Create(CreateSuspended);
77	77		end;
78	78		```
79	79
80	80		``` pascal
81	81		procedure TMyThread.ShowStatus;
82	82		// this method is executed by the mainthread and can therefore access all GUI elements.
83	83		begin
84	84		Form1.Caption := fStatusText;
85	85		end;
86	86		```
87	87
88	88		``` pascal
89	89		procedure TMyThread.Execute;
90	90		var
91	91		newStatus : string;
92	92		begin
93	93		fStatusText := 'TMyThread Starting...';
94	94		Synchronize(@Showstatus);
95	95		fStatusText := 'TMyThread Running...';
96	96		while (not Terminated) and ([any condition required]) do
97	97		begin
98	98		...
99	99		[here goes the code of the main thread loop]
100	100		...
101	101		if NewStatus <> fStatusText then
102	102		begin
103	103		fStatusText := newStatus;
104	104		Synchronize(@Showstatus);
105	105		end;
106	106		end;
107	107		end;
108	108		```
109	109
110	110		Voici l'application :
111	111
112	112		``` pascal
113	113		var
114	114		MyThread : TMyThread;
115	115		begin
116	116		MyThread := TMyThread.Create(True); // This way it doesn't start automatically
117	117		...
118	118		[Here the code initialises anything required before the threads starts executing]
119	119		...
120	120		MyThread.Start;
121	121		end;
122	122		```
123	123
124	124		Si vous voulez rendre votre synchronisation plus flexible vous pouvez créer un événement pour cette tâche - de cette façon votre méthode synchronized ne sera pas étroitement couplée avec une fiche spécifique ou une classe - il suffit ensuite d'avoir une méthode répondant à l'évènement du thread. Voici un exemple :
125	125
126	126		``` pascal
127	127		Type
128	128		TShowStatusEvent = procedure(Status: String) of Object;
129	129
130	130		TMyThread = class(TThread)
131	131		private
132	132		fStatusText : string;
133	133		FOnShowStatus: TShowStatusEvent;
134	134		procedure ShowStatus;
135	135		protected
136	136		procedure Execute; override;
137	137		public
138	138		Constructor Create(CreateSuspended : boolean);
139	139		property OnShowStatus: TShowStatusEvent read FOnShowStatus write FOnShowStatus;
140	140		end;
141	141		```
142	142
143	143		``` pascal
144	144		constructor TMyThread.Create(CreateSuspended : boolean);
145	145		begin
146	146		FreeOnTerminate := True;
147	147		inherited Create(CreateSuspended);
148	148		end;
149	149		```
150	150
151	151		``` pascal
152	152		procedure TMyThread.ShowStatus;
153	153		// this method is executed by the mainthread and can therefore access all GUI elements.
154	154		begin
155	155		if Assigned(FOnShowStatus) then
156	156		begin
157	157		FOnShowStatus(fStatusText);
158	158		end;
159	159		end;
160	160		```
161	161
162	162		``` pascal
163	163		procedure TMyThread.Execute;
164	164		var
165	165		newStatus : string;
166	166		begin
167	167		fStatusText := 'TMyThread Starting...';
168	168		Synchronize(@Showstatus);
169	169		fStatusText := 'TMyThread Running...';
170	170		while (not Terminated) and ([any condition required]) do
171	171		begin
172	172		...
173	173		[here goes the code of the main thread loop]
174	174		...
175	175		if NewStatus <> fStatusText then
176	176		begin
177	177		fStatusText := newStatus;
178	178		Synchronize(@Showstatus);
179	179		end;
180	180		end;
181	181		end;
182	182		```
183	183
184	184		Voici l'application :
185	185
186	186		``` pascal
187	187		Type
188	188		TForm1 = class(TForm)
189	189		Button1: TButton;
190	190		Label1: TLabel;
191	191		procedure FormCreate(Sender: TObject);
192	192		procedure FormDestroy(Sender: TObject);
193	193		private
194	194		{ private declarations }
195	195		MyThread: TMyThread;
196	196		procedure ShowStatus(Status: string);
197	197		public
198	198		{ public declarations }
199	199		end;
200	200		```
201	201
202	202		``` pascal
203	203		procedure TForm1.FormCreate(Sender: TObject);
204	204		begin
205	205		inherited;
206	206		MyThread := TMyThread.Create(true);
207	207		MyThread.OnShowStatus := @ShowStatus;
208	208		end;
209	209		```
210	210
211	211		``` pascal
212	212		procedure TForm1.FormDestroy(Sender: TObject);
213	213		begin
214	214		MyThread.Terminate;
215	215		MyThread.Free;
216	216		inherited;
217	217		end;
218	218		```
219	219
220	220		``` pascal
221	221		procedure TForm1.Button1Click(Sender: TObject);
222	222		begin
223	223		MyThread.Start;
224	224		end;
225	225		```
226	226
227	227		``` pascal
228	228		procedure TForm1.ShowStatus(Status: string);
229	229		begin
230	230		Label1.Caption := Status;
231	231		end;
232	232		```
233	233
234	234		# Choses spéciales dont il faut s'occuper
235	235
236	236		Il y a une prise de tête potentielle dans Windows avec les Threads si vous employez l'option -Ct (contrôle de pile ). Pour des raisons obscures le contrôle de pile se "déclenchera" sur un quelconque TThread.Create si vous employez la taille de pile par défaut. Le seul contournement(à ce problème) pour le moment est simplement de ne pas utiliser l'option -Ct. Noter qu'il ne cause pas d'exception dans la tâche principale, mais dans celle nouvellement crée. Ainsi, tout se passe comme si la tâche n'avait jamais commencée.
237	237
238	238		Voici un code correct permettant de vérifier les exceptions qui peuvent se produire dans la création d'une tâche:
239	239
240	240		``` pascal
241	241		MyThread:=TThread.Create(False);
242	242		if Assigned(MyThread.FatalException) then
243	243		raise MyThread.FatalException;
244	244		```
245	245
246	246		Ce code assure que toute exception qui se produit pendant la création d'une tâche soit relevée (et traitée) dans votre tâche principale.
247	247
248	248		# Les unités nécessaires pour une application multi-tâches
249	249
250	250		Vous n'avez besoin d'aucune unité spéciale pour ceci pour travailler avec Windows . Cependant avec Linux, MacOSX et FreeBSD, vous avez besoin de l'unité cthreads et elle doit être la première untité utilisée du projet (l'unité du programme , .lpr)!
251	251
252	252		Ainsi, votre code d'application Lazarus devrait resssembler à :
253	253
254	254		``` pascal
255	255		program MyMultiThreadedProgram;
256	256		{$mode objfpc}{$H+}
257	257		uses
258	258		{$ifdef unix}
259	259		cthreads,
260	260		{$endif}
261	261		Interfaces, // this includes the LCL widgetset
262	262		Forms
263	263		{ add your units here },
264	264		```
265	265
266	266		Si vous oubliez ceci vous obtiendrez cette erreur au démarrage :
267	267
268		-	~~` Le fichier binaire n'a aucun support de tâches compilé en lui.`\~~
269		-	~~` Recompiler l'application avec un gestionnaire de thread dans la clause uses du programme avant d'autres unités utilisant`\~~
270		-	~~` les tâches. (Pour le message en anglais voir version anglaise de cette page)`~~
	268	+	``` pascal
	269	+	Le fichier binaire n'a aucun support de tâches compilé en lui.
	270	+	Recompiler l'application avec un gestionnaire de thread dans la clause uses du programme avant d'autres unités utilisant
	271	+	les tâches. (Pour le message en anglais voir version anglaise de cette page)
	272	+	```
271	273
272	274		# Support SMP
273	275
274	276		La bonne nouvelle est que votre application travaille en multi-tâches correctement de cette façon, elle est déjà prête pour le SMP!
275	277
276	278		# Deboguer les application multi-tâches avec Lazarus
277	279
278	280		Le deboguage sur Lazarus n'est pas encore entièrement fonctionnel.
279	281
280	282		## Deboguer la sortie
281	283
282	284		Dans une application a une seule tâche, vous pouvez simplement écrire sur la console/le terminal/n'importe quoi et l'ordre des lignes est le même avec lesquelles elles ont été écrites . Dans une application multi-tâche les choses sont plus compliquées. Si deux tâches écrivent, c'est à dire qu'une ligne est écrite par la tâche A avant une ligne par la tâche B, alors les lignes ne sont pas neccessairement écrites dans cet ordre. Il peut même se produire qu'une tâche écrive sa propre sortie pendant qu'une autre tâche soit déjà en train d'écrire sur la sortie, résultant en des lignes qui se mélangent.
283	285
284	286		L'unité LCLProc contient plusieurs fonctions , pour laisser chaque tâche écrire à son propre fichier journal:
285	287
286	288		``` pascal
287	289		procedure DbgOutThreadLog(const Msg: string); overload;
288	290		procedure DebuglnThreadLog(const Msg: string); overload;
289	291		procedure DebuglnThreadLog(Args: array of const); overload;
290	292		procedure DebuglnThreadLog; overload;
291	293		```
292	294
293	295		Par exemple : Au lieu de writeln('Some text ',123); utilisez
294	296
295	297		``` pascal
296	298
297	299		DebuglnThreadLog(['Some text ',123]);
298	300		```
299	301
300	302		Ceci ajoutera une ligne 'Some text 123' à Log\<PID\>.txt, où \<PID\> est l'ID du processus de la tâche courante.
301	303
302	304		C'est une bonne idée d'enlever le fichier journal avant chaque exécution :
303	305
304		-	~~` rm -f Log* && ./project1`~~
	306	+	```text
	307	+	rm -f Log* && ./project1
	308	+	```
305	309
306	310		## Linux
307	311
308	312		Si vous essayez de deboguer une application multi-tâches sous Linux, vous aurez un grand problème : le serveur X va crasher !
309	313
310	314		On ne sait pas comment résoudre cela proprement, mais un contournement de ce problème est:
311	315
312	316		Créer une nouvelle instance de X avec :
313	317
314		-	~~` X :1 &`~~
	318	+	```text
	319	+	X :1 &
	320	+	```
315	321
316	322		Il s'ouvrira, et quand vous commuterez vers un autre bureau (celui avec lequel vous travaillez en appuyant sur CTRL+ALT+F7), vous pourrez retourner vers le nouveau bureau graphique avec CTRL+ALT+F8 (si cette combinaison ne fonctionne pas , essayez avec CTRL+ALT+F2... celui-ci a fonctionné avec Slackware).
317	323
318	324		Alors vous pourriez , si vous voulez , créer une session bureau au démarrage de X avec:
319	325
320		-	~~` gnome-session --display=:1 &`~~
	326	+	```text
	327	+	gnome-session --display=:1 &
	328	+	```
321	329
322	330		Puis, dans Lazarus, avec la boite de dialogue "paramètres d'exécution..." du menu Exécuter, cocher "Utiliser l'affichage" et entrez :1.
323	331
324	332		Maintenant l'application s'exécutera sur le deuxième serveur X et vous serez capable de la déboguer avec le premier.
325	333
326	334		Ceci a été testé avec Free Pascal 2.0 et Lazarus 0.9.10 sur Windows et Linux.
327	335
328	336		------------------------------------------------------------------------
329	337
330	338		Au lieu de créer une nouvelle session X, on peut employer [Xnest](http://en.wikipedia.org/wiki/Xnest). Xnest est une session X session sur une fenêtre . En l'utilisant, le serveur X n'est pas bloqué pendant le debogage des processus, et c'est beaucoup plus facile de deboguer sans être tenu de changer de terminals.
331	339
332	340		La ligne de commande pour exécuter Xnest est
333	341
334		-	~~` Xnest :1 -ac`~~
	342	+	```text
	343	+	Xnest :1 -ac
	344	+	```
335	345
336	346		pour créer une session X sur :1, et interdire de contrôle d'accès.
337	347
338	348		# Widgetsets
339	349
340	350		Les interfaces win32, gtk et carbon supportent entièrement le multi-tâches. Ceci signifie que, TThread, les sections critiques et Synchronize fonctionnent.
341	351
342	352		# Les sections critiques
343	353
344	354		Une section critique est un objet employé pour s'assurer, qu'une certaine partie du code est exécutée seulement par une tâche à la fois. Une section critique doit être créée /initialisée avant qu'elle puisse être employée et être libérée quand elle n'est plus nécessaire.
345	355
346	356		Les sections critiques sont normalement employées de cette façon :
347	357
348	358		Ajouter l'unité SyncObjs.
349	359
350	360		Déclarer la section (de manière globale pour toutes les tâches qui devraient accéder à la section):
351	361
352	362		``` pascal
353	363		MyCriticalSection: TRTLCriticalSection;
354	364		```
355	365
356	366		Créer la section :
357	367
358	368		``` pascal
359	369		InitializeCriticalSection(MyCriticalSection);
360	370		```
361	371
362	372		Executer quelques tâches. En faisant quelque chose exclusivement
363	373
364	374		``` pascal
365	375		EnterCriticalSection(MyCriticalSection);
366	376		try
367	377		// accéder à quelques variables , écrire les fichiers , envoyer quelques paquets de réseau , etc
368	378		finally
369	379		LeaveCriticalSection(MyCriticalSection);
370	380		end;
371	381		```
372	382
373	383		Après que toutes les tâches soient terminées , libérer la section critique :
374	384
375	385		``` pascal
376	386		DeleteCriticalSection(MyCriticalSection);
377	387		```
378	388
379	389		Comme alternative, vous pouvez employer un objet TCriticalSection. La création fait l'initialisation, la méthode Enter fait pénétrer dans EnterCriticalSection, la méthode Leave fait LeaveCriticalSection et la destruction de l'object fait la suppression.
380	390
381	391		Par exemple : 5 tâches incrémentant un compteur. Voir lazarus/examples/multithreading/criticalsectionexample1.lpi
382	392
383	393		PRENDRE GARDE : Il y a deux jeux pour les 4 fonctions ci-dessus. Celui de la bibliothèque RTL et celui de la LCL. Celui de la LCL est défini dans les unités LCLIntf et LCLType. Tous les deux fonctionnent plus ou moins de la même façon . Vous pouvez les employer tous les deux en même temps dans votre application , mais vous ne devriez pas employer une fonction de la bibliothèque RTL avec une section critique LCL et vice-versa.
384	394
385	395		## Partage de variables
386	396
387	397		Si certaines tâches partagent une variable, seulement en lecture, alors il n'y a pas à s'inquiéter. juste la lire. Mais si une ou plusieurs tâches modifient la variable, alors vous devez vous assurer , que seulement une tâche accède aux variables à la fois .
388	398
389	399		Par exemple : 5 tâches incrémentant un compteur. Voir lazarus/examples/multithreading/criticalsectionexample1.lpi
390	400
391	401		# Attente une autre tâche
392	402
393	403		Si une tâche A a besoin du résultat d'une autre tâche B, elle doit attendre , jusqu'à ce que B ait fini .
394	404
395	405		Important: La tâche principale ne devrait jamais attendre pour une autre tâche. Au lieu de cela utilisez Synchronize (voir ci-dessus).
396	406
397	407		Pour un exemple voir: lazarus/examples/multithreading/waitforexample1.lpi
398	408
399	409		``` pascal
400	410		{ TThreadA }
401	411
402	412		procedure TThreadA.Execute;
403	413		begin
404	414		Form1.ThreadB:=TThreadB.Create(false);
405	415		// create event
406	416		WaitForB:=RTLEventCreate;
407	417		while not Application.Terminated do begin
408	418		// wait infinitely (until B wakes A)
409	419		RtlEventWaitFor(WaitForB);
410	420		writeln('A: ThreadB.Counter='+IntToStr(Form1.ThreadB.Counter));
411	421		end;
412	422		end;
413	423
414	424		{ TThreadB }
415	425
416	426		procedure TThreadB.Execute;
417	427		var
418	428		i: Integer;
419	429		begin
420	430		Counter:=0;
421	431		while not Application.Terminated do begin
422	432		// B: Working ...
423	433		Sleep(1500);
424	434		inc(Counter);
425	435		// wake A
426	436		RtlEventSetEvent(Form1.ThreadA.WaitForB);
427	437		end;
428	438		end;
429	439		```
430	440
431	441		# Fork
432	442
433	443		Prenez garde au fait que lorsque vous forkez une application multi-threads, tous les threads créés et s'exécutant avant l'appel à fork (ou fpFork) ne seront pas exécutés dans le processus enfant. Comme indiqué dans la 'man page' de la fonction fork(), tous les threads qui sont en cours d'exécution avant l'appel à fork seront dans un état indéterminé.
434	444
435	445		Donc attention a toutes les thread s'initialisant avant l'appel d'un fork (même dans la section initialization ). Ils ne fonctionneront pas.
436	446
437	447		# procédures/boucles parallèles
438	448
439	449		Un cas particulier de multi threading est exécute une procédure unique en parallèle. Voir [[Parallel procedures/fr\|procédures Parallèles]].
440	450
441	451		# Traitement distribué / Distributed computing
442	452
443	453		Le prochain grand pas après le 'multi-threading' est d'exécuter des threads sur plusieurs machines.
444	454
445	455		- Vous pouvez utiliser une des suites TCP comme synapse, lnet ou indy pour la communication. Cela vous donnera le maximum de flexibilité et est surtout utilisé dans les applications client / serveur.
446	456		- Vous pouvez utiliser une bibliothèque de passage de message comme [[MPICH]], utilisé sur le clusters pour 'HPC' (High Performance Computing).
447	457
448	458		---
449	459		From the Free Pascal wiki, page "Multithreaded Application Tutorial/fr", as it stood on 2020-02-20 after a change by Trev, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history