#!/usr/bin/perl
for(;;){}
hatására az egész webszervert le kell állítani, hogy újra normális válaszidőket tudjon adni.
Ezen egyébként valamennyit segít az IIS4.0, mert egyes könyvtárakhoz külön processzt lehet
rendelni a webszerver konfigurációja során.
Van azonban néhány komolyabb bug is az ISAPI filterként megírt Perl interpreterben. Az egyik ilyen, hogy a környezeti változók %ENV hash-ét nem tölti fel a lehetséges értékekkel a webszerver, vagy a Perl interpreter, és így ha végigakarunk menni az összes értéken, akkor csak egy értéket ad vissza. Ugyanakkor ha valamelyik konkrét elemére hivatkozunk, akkor gyorsan megnézi, hogy van-e olyan eleme a hash-nek, és jól működik. Mivel általában ezzel nincs gond, hiszen ennek a tömbnek az elemein csak ennek a példának a kedvéért szoktunk egyenként végigmenni, ezért ez nem szokott gondot okozni. Van azonban pár egyéb probléma is. Az ISAPI változat nem képes socket-et kezelni, és ezért például nem lehet SMTP levelet küldeni vele CGI script-ből.
Szerencsére, ha ugyanennek a cégnek a Perl.exe programjával futtatom a scriptet, és igazi CGI, külön processzben futó scriptről van szó, akkor ezek a hibák elmúlnak. A saját megoldásom ezzel kapcsolatban az, hogy minden olyan Perl script, amelyik használ(hat) olyan funkciókat, amelyet az ISAPI verzió nem kezel helyesen létrehozok a .pl kiterjesztés mellett egy .plx kiterjesztésű változatot is. Ha például az eredeti script neve xxx.pl akkor a .plx kiterjesztésű változat semmi mást nem tartalmaz, mint egy do 'xxx.pl' utasítást.
Amikor olyan funkcióra van szükség, amely nem érhető el az ISAPI változattal, akkor a .plx
kiterjesztésű scriptre hivatkozunk. Ehhez még annyit kell megtenni, hogy a registry-ben a
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Script Map]
".plx"="C:\\PERL\\BIN\\PERL.EXE %s %s"
bejegyzéseket is meg kell tenni.
. . . . . .
