Discussion :

[kirbby]

J'ai un petit code qui sur le papier devrait bien marcher mais seulement quand je le lance ben ça marche nettement moins bien

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
use threads;
use strict;
use DBI;
use warnings;
use diagnostics;
 
my @pth;
my $ptiming;
my $rep;
my $database = "...";
my $hostname = "localhost";
my $login = "root";
my $mdp = "";
my $dsn = "DBI:mysql:$database:$hostname";
my $sth;
my $dbh;
 
threads->new(\&main)->join;
 
sub main 
{
	while(1)
	{
		$dbh = DBI->connect($dsn,$login,$mdp) or die "ECHEC connexion";
		@pth = ();
		for(my $i=0;$i<20;$i++)
		{
			$pth[$i] = threads->new(\&subroutine);
		}
		$ptiming = threads->new(\&timing);
		$ptiming->join;
		for(my $j=0;$j<20;$j++)
		{
			$rep = $pth[$j]->join;
			$sth = $dbh->prepare("INSERT INTO test VALUES('test')");
			$sth->execute();	
		}
		$dbh->disconnect
	}
}
 
sub subroutine
{
	return "oO";
}
 
sub timing
{
sleep(0);
}

Donc le premier tour de boucle se passe bien mais après, un warning sur le premier insert du 2eme tour et sur le 2 insert perl plante :

Use of uninitialized value in null operation during global destruction (#1)
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
To suppress this warning assign a defined value to your variables.

To help you figure out what was undefined, perl tells you what operation
you used the undefined value in. Note, however, that perl optimizes your
program and the operation displayed in the warning may not necessarily
appear literally in your program. For example, "that $foo" is
usually optimized into "that " . $foo, and the warning will refer to
the concatenation (.) operator, even though there is no . in your
program.

Use of uninitialized value in null operation during global destruction (#1)
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
To suppress this warning assign a defined value to your variables.

To help you figure out what was undefined, perl tells you what operation
you used the undefined value in. Note, however, that perl optimizes your
program and the operation displayed in the warning may not necessarily
appear literally in your program. For example, "that $foo" is
usually optimized into "that " . $foo, and the warning will refer to
the concatenation (.) operator, even though there is no . in your
program.

Argument "NAME" isn't numeric in null operation during global destruction (#2)
(W numeric) The indicated string was fed as an argument to an operator
that expected a numeric value instead. If you're fortunate the message
will identify which operator was so unfortunate.

Ca c'est tout le blabla auquel j'ai droit mais qui ne m'avance pas plus que ça ...Si quelqu'un avait une idée !?

[Jedai]

Evite d'utiliser les threads, sauf si tu en as absolument besoin, tu peux me dire ce que tu as essayé de faire ?

--
Jedaï

[heygeo]

Bonjour,

J'ai exactement le même souci avec mon programme en PERL.
Je suis obligé d'utiliser les threads, mon programme lance un certain nombre de processus en parallèle.

Par contre, a noter que sur mon serveur de developpement, je n'ai aucun message, alors que sur un autre serveur (celui de validation) j'ai ce problème.

Des idées ?

[heygeo]

J'avance un peu.
Entre mes deux serveurs, la version de DBI n'etait pas la meme.
Celle du serveur de dev (où il n'y avait pas d'erreur) etait plus ancienne.

Après mise à jour, le serveur de dev fait les memes erreurs que celui de validation !

Donc c'est en rapport avec DBI.

[heygeo]

J'ai une theorie :

Lorsqu'on ouvre plusieurs connections avec DBI avec les threads, en realité un seul handle avec l'objet mysql est partagé entre les threads, ce qui provoque des erreurs à la destruction des threads, lorsque PERL essaye de nettoyer les variables.

Mais alors, comment faire ?

[heygeo]

J'ai reussi a regler le probleme.

Quand un thread est cree, toutes les variables en cours d'utilisation sont recopiees depuis le thread pere.

Il ne faut donc, au moment ou l'on lance le thread, qu'aucune variable pointant sur DBI ne soit presente, meme si la base est deconnectee.

Exemple qui ne fonctionne pas :

Code :

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

1
2
3
my $h_DataBase=h_fConnect($MsqlServ,$MsqlDb,$MsqlUser,$MsqlPass);
$h_DataBase->disconnect();
my $thr = threads->new(\&mon_thread);

ici $h_DataBase existe lorsque le thread est cree, a la destruction du thread cela pose probleme.

Si je mets ma variable de base dans un bloc de code :

Code :

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

1
2
3
4
5
6
if (1)
{
      my $h_DataBase=h_fConnect($MsqlServ,$MsqlDb,$MsqlUser,$MsqlPass);
      $h_DataBase->disconnect();
}
my $thr = threads->new(\&mon_thread);

la variable est detruite a la sortie du bloc de code, et ca marche !
C'est pas pratique, mais ca fonctionne.