Onderwerp: Mod_Perl concurency probleem

Ik heb een script waarin vrij vertaald het volgende gebeurd.

Code:

sub toonfoto
{
  my ($y,$f,$fp) = @_;
  my $photopath="$fp/$y$f";
  print "<img src=\"$photopath\">)
}
our $fotodir="/fotos/nedlinux";
my $jaar=param('jaar');
my $photo=param('photo');

# taint flauwekul
blah blah
toonfoto($photo,$jaar,$fotodir);

Nog maals het is maar een vrije vertaling van wat er werkelijk gebeurd.
Op zich werkt dit script prima, althans dat heeft het ruim een half jaar gedaan.
Probleem is nu dat het nu op een machine draaid met 4 * 64bit CPU en mod_perl ipv oude cgi

Nog steeds werkt het script ,
maar zodra er meerdere gebruikers van het script gebruik maken,
dan krijg ik regelmatig de verkeerde foto's en het verkeerde jaar.
Oorzaak bekend (apache multi threading en meerdere CPU's), oplossing niet
Wie ohhh Wie ?

p.s. sorry het is een xpost met nedlinux
maar ik verwacht gewoon wat weinig response vandaar ;(

Denk niet zozeer dat multi-threading + meerdere CPU's het probleem is, maar dat multi-threading + meerdere CPU's + mod_perl het probleem is. mod_perl houdt het programma resistent in het geheugen, waardoor variabelen niet meer gereset worden naar de initiele waarden en je rekening moet gaan houden met verschillen threads.

Het kan bijvoorbeeld zijn dat localtime() of de fs-functies niet thread-safe zijn.

Zie ook http://perl.apache.org/docs/2.0/user...Under_mod_perl

Aloha,

Martin

Dank je Martin.

Ik heb ook gemerkt dat er sinds mod_perl v.s. Apache2 een enorm verschil staat tussen het gebruik van MY en OUR.
Ik denk ook dat ik daar het probleem in moet zoeken.
maar ik ben nog nergens DOC tegen gekomen die het fijne ervan verteld.

Perl ondersteunt welliswaar multi-threading,
al word daar in Perl-5 nog geen garantie aan gegeven,
het gaat hier echter niet om een PERL apllicatie maar om de runtime envirement.
(maar dat wist jij uiteraard ook al)

Ik baal ervan dat ik dit niet kan terug vinden.
Zal nog es op de Apache link kijken.
TNX

Hmmm....

Ik maak gebruik van een globale variabele
die door een functie wordt volgeduwd
en door een andere functie word uitgelezen.

MY @FOTOS;

sub lees
{
@FOTOS=<FOTOLIJST>;
}

sub scrhijf
{
print @FOTOS;
}

dat zou wel eens tot elende kunnen leiden.
maar hoe lost ik dat op zonder de hele winkel om te moeten bouwen ?

Origineel geplaatst door Capt.Pascal
Hmmm....

Ik maak gebruik van een globale variabele
die door een functie wordt volgeduwd
en door een andere functie word uitgelezen.

MY @FOTOS;

sub lees
{
@FOTOS=<FOTOLIJST>;
}

sub scrhijf
{
print @FOTOS;
}

dat zou wel eens tot elende kunnen leiden.
maar hoe lost ik dat op zonder de hele winkel om te moeten bouwen ?

Zet eens 'use strict;' bovenaan het script, en los alle foutmeldingen op.. dan ben je al een stuk verder gok ik. use strict elimineert globale variablen en vereist dat je je variablen declareert.

Hoi Rick
Dank voor je reactie.

Uiteraard gebruik ik ALTIJD strict en
uiteraard ook de W en de T flags he
strict verbied geen globale variabelen
het vereist enkel dat je ze declareerd.
Daarmee kan echter nog genoeg fout gaan.

zie het vogende voorbeeld

Code:

use braaf_zoals_rik_ het_ zegt STRICT;
my $tijd=time();

sub doedom
{
  my ($a,$b);
  $tijd="Hallo $a $b\n";
  print $tijd;
}

print "$tijd\n";
doedom("pascal",$tijd);
print "$tijd\n";

Om maar eens een typisch dom voorbeeldje te noemen.
met grote programma's kan je zoiets best gebeuren.

Als my vs. our en threads inderdaad het probleem zijn, dan zit ik er sterk aan te denken om alles in een klasse te stoppen (OO-perl).

Je krijgt dan zoiets als:

1. Request
2. Instantiate foto-klasse
3. Invoke / execute foto-klasse
4. Tear down / delete foto-klasse
5. End request

Iedere request krijgt dan zijn eigen foto-klasse met zijn eigen variabelen.

Iemand enig idee of dit idee ook werkt?

Aloha,

Martin

Hmmm
ik hoop dat dat niet nodig is
zie ook niet direct waarom dat het probleem zou oplossen
wat ik met MY declareer is tenslote net zo local als je in een classe mag verwachten.
in C++ heb ik gemerkt dat je met multithreading ook de nodige elende kan krijgen.
jeetje... sinds die tijd verf ik mijn haren <bloos>
Bovendien (nogmaals) mijn applicatie is niet multithreading he,
het is apache die vrolijke kunstjes doet.

Wat ik eigenlijk probeerde duidelijk te maken was om de huidige globale variabelen uit de global scope te krijgen.

Dit zodat de globale variabelen nu bij de 2e en volgende aanroepen de waarden uit de eerste aanroep gebruiken.
(mod_perl start een script niet opnieuw op, maar hergebruikt dit).

Andere ideeen heb ik niet meer. Laat je oplossing even weten).

Tot slot nog wat extra leesvoer:
http://perl.apache.org/docs/1.0/guide/porting.html

Aloha,

Martin

PS. Zodra je multithreading gaat programmeren moet je eigenlijk ook gebruik gaan maken van mutexes, en aanverwanten.

Ja Martin,

Dat laatste weet ik uiteraard ook
Maar nogmaals,
ik programeer niet multithreading.
Mijn programma heeft ook altijd prima gedraaid.
Probleem is dat apache2 nu met meerdere thread, meerdere processen over meerdere CPU's draaid.
en dan word het ineens een heel ander verhaal.

zal me nog es diep in mod perl moeten duiken.
Alsof ik daar tijd voor heb ;(

Ik laat je weten
als ik het opgelost heb

Ik heb het als volgt weten op te lossen

Code:

sub lees
{
  return=<FOTOLIJST>;
}

sub scrhijf
{
  my @FOTOS=@_;
  print @FOTOS;
}

if($pascal eq "verrekte cool")
{
  my @FOTOS = lee();
  schrijf(@FOTOS);
}

Dus gewoon afgestapt van globale variabelen die in elke thread anders zijn.
daarmee is het probleem opgelost

Om de een of andere reden zijn globale variabelen binnen functies kenlijk niet meer te gebruiken.
niet erg, maar moet je wel weten.
zou het ergens gedoct staan ?

Ik kan ook nog steeds niet vinden hoe binnen MOD_PERL nou precies word omgegaan met my en our
Er zit wel duidelijk verschil in... dat wel

Tnx annyhow.

Origineel geplaatst door Capt.Pascal

Dus gewoon afgestapt van globale variabelen die in elke thread anders zijn.
daarmee is het probleem opgelost

Wat ik denk dat je bedoelt is, "geen globale variabelen gebruiken om local state in te bewaren". En ja, da's inderdaad een goeie zaak .

Dus als je iets buiten een local scope wijzigt moet je het eerst 'locken', dan wijzigen en vervolgens 'unlocken'. Verder zoals al gezegd moet je er niet vanuit gaan dat bij het hergebruiken van variabelen deze variabelen automatisch 'gezeroed/reset' zijn. Altijd variabelen init'en naar wat je ze op wil hebben.

Voor Apache2 mod_perl2 zou ik hier eens mee aan de slag gaan,

http://perl.apache.org/docs/2.0/api/APR/Pool.html
http://perl.apache.org/docs/2.0/api/...readMutex.html

'APR' = Apache Portable Runtime.

Wikipedia over Threads,
http://en.wikipedia.org/wiki/Multithreading

Mutexes,
http://en.wikipedia.org/wiki/Mutex

HTH

Wat ik denk dat je bedoelt is, "geen globale variabelen gebruiken om local state in te bewaren". En ja, da's inderdaad een goeie zaak .

Verdomd ja, en ik ben het nog met je eens ook.
Het leek me aleen zo relaxed om te doen he.
Komen we weer op de eeuwige discussie over het gebruik van globale variabelen
en complexe (nou ja) situatie.
Genoeg elende gehad met prutsers die dat niet inzagen.
Maar ja, dan ging het om compiler talen (Fortran, C, CPP) in hard realtime omgevingen

Dus als je iets buiten een local scope wijzigt moet je het eerst 'locken', dan wijzigen en vervolgens 'unlocken'.

Leuk bedacht, maar hoe doe je dat in PERL ?
vergeet niet dat PERL 5 welliswaar multithreading ondersteunt maar dat expliciet vermeld word dat de garantie daarop net gisteren verlopen is !

Verder zoals al gezegd moet je er niet vanuit gaan dat bij het hergebruiken van variabelen deze variabelen automatisch 'gezeroed/reset' zijn. Altijd variabelen init'en naar wat je ze op wil hebben.

Ja dat spreekt dan vanzelf.
Ik kreeg dan ook waardes van andere threads.

Gelukkig had ik dit probleem in mijn zelfbopuw Apache2 Access handler al zien aankomen en heb daar dus ook globale scalars achterwege gelaten.
Maar das ook simpel want die hele handel is daar OOP en dan ben je dom als je het dan nog niet snapt.
ehhh... of zoiets ... denk ik....
mischien...

Annyhow
TNX op naar de volgende stupiditeit

Origineel geplaatst door Capt.Pascal

Leuk bedacht, maar hoe doe je dat in PERL ?
vergeet niet dat PERL 5 welliswaar multithreading ondersteunt maar dat expliciet vermeld word dat de garantie daarop net gisteren verlopen is !

Als ik die API links eens bekijk zal het zoiets zijn,

Code:

use APR::Pool ();
use APR::ThreadMutex ();

my $pool = APR::Pool->new;
my $mutex = APR::ThreadMutex->new($pool);

$mutex->lock;
/* Perform Voodoo(tm) */
$mutex->unlock;

$mutex->destroy;
$pool->destroy;

En dan ipv 'lock', 'trylock' in een loop.

Annyhow
TNX op naar de volgende stupiditeit

np! Ik zal je mijn lijst met 'WTF?' momenten besparen - 'leermomenten' noemen we dat maar .

TNX for the Info.
Had ik natuurlijk zelf ook ff kunnen uitzoeken,
maar ik heb het zo sterves druk.
Zit de hele dag achter een zooitje van die stompzinnige beeldschermen,
terwijl ik veel liever met je jeepje zou gaan karren, een boek lezen, wat knutselen
of gewoon gaan wandelen.
Maar ja dat betaald allemaal geen rekeningen he.

Annyhow idd $WTF++