Thread et mysql

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:

---

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 !?

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

--
Jedaï

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 ?

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.

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 ?

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:

---

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:

---

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.

Non, on n'est pas obligé d'utiliser les threads. Les threads, c'est joli, mais c'est délicat. Pour ce que j'en ai vu, c'est très sensible à ce qu'on fait et on a vite fait de déborder de la taille des segments de mémoire réservé pour chaque thread. C'est très très pénible, et le code n'est pas robuste.

Pour lancer des choses en parallèle, il y a d'autres solutions. Faire des fork avec des selects, ou bien utiliser POE (que personnellement, je trouve à la fois passionnant et d'une syntaxe très obscure :roll: ).

Si tu dois absolument multithreader ton application c'est très simple laisse tomber perl. Les threads en perl sont pas trop