[Perl] FileHandles en Windows....

[Gunnar Wolf]

>     Si, ya hace mucho habia visto esa posibilidad, y la verdad no le
> entendi. Y por lo general si es complicado de explicar/entender, entonces=
 es
> complicado de usar. Lo volvi a ver y sigo si entenderle("man perltie" est=
=E1
> mas completo), muy seguramente porque se maneja como objeto y a mi
> penosamente no se me da eso...

Yo tampoco soy nada aficionado de los objetos, aunque es necesario usarlos
:) pero no te preocupes, ac=E1 tu archivo se convierte m=E1gicamente en un
hash cualquiera.

>     Adem=E1s, por ahi mencionaron que se manejan como binarios, pues no m=
e
> sirve entonces. Por lo que sale mas barato comprarle m=E1s memoria a la c=
ompu
> que usar     TIEs para mi caso. Tambien quien sabe como le hagas para
> relacionar una tabla con otra... como yo lo hago es f=E1cil gracias a per=
l:
>
> my %Usuarios=3D&GETNDBFILE1("usuarios.ndb");
> my %Ordenes=3D&GETNDBFILE1("ordenes.ndb");
> my $IDord=3D50;
> print "La orden $IDord la hizo
> $Usuarios{$Ordenes{$IDord}{'IDUSUARIO'}}{'NOMBRE'}.";

Esto te sigue sirviendo. Claro, tienes que fijarte bien c=F3mo manejas las
referencias - No recuerdo la situaci=F3n exacta, pero me parece que en caso=
s
como este puede que tu hash amarrado en el disco no est=E9 guardando
valores, sino que apuntadores a tu memoria... Lee la p=E1gina :)

> Sin embargo, mi objetivo es hacer una nueva funcion con algo parecido a:
>
> my %Usuarios=3D&GETNDBFILE2("select * from usuarios where estado=3D1 orde=
rby
> nombre");
>
>     Aqui seguirias usando los archivos NDB, pero los accesas tipo SQL,
> ahorrandote memoria ya que usarias el where, y luego ordenados con el
> orderby, todo lo que no hace mi funci=F3n actual. Aunque creo que eso ya =
lo
> hace el DBI con archivos planos. El problema aqui es hacer el parser SQL.
> Eso me mantendr=E1 entretenido un buen rato. =3D)

En este caso, y si dices que los archivos te los pasan de Excel, tal vez
lo m=E1s f=E1cil sea que te los pasen en formato DBF y que uses el m=F3dulo
Xbase (que puedes usar como m=F3dulo independiente con sus propios comandos=
,
o a trav=E9s de DBI como un DBD m=E1s).

> >Yo creo que se debe a la manera en que Unix y Windows manejan la
> >memoria... Probablemente en Windows Perl tenga que estarle pidiendo al
> >kernel m=E1s y m=E1s pedazos de memoria, lo cual toma bastante tiempo (y=
a
> >conoces la afici=F3n de Windows de 'thrashear' con la memoria virtual). =
En
> >los Unixes que conozco, el manejo de memoria es mucho m=E1s limpio y
> >eficiente.
>
>     Pos quien sabe, yo creo que esta mal el PERL para Windows... deberia =
de
> matar el FileHandle con el close. Si fuera de Windows, se tardar=EDa igua=
l
> aunque trasheara la memoria.

La bronca no es el filehandle, sino que tu programa requiere cada vez m=E1s
espacio en memoria... Y -afortunadamente :)- no conozco los algoritmos de
asignaci=F3n de memoria de Windows, as=ED como tampoco conozco el
funcionamiento de su scheduler... Podr=EDa ser (aunque se me har=EDa idiota=
)
que requiera cargar la im=E1gen completa de tu programa en memoria real par=
a
ejecutarlo, por lo que cada que tu programa entra y sale de contexto
tendr=E1 que hacer grand=EDsimas transferencias... Puede que sea que el swa=
p
de Windows es un vil archivote dentro del filesystem, que se fragmenta
cual cualquier archivo, que tiene que pasar por varias capas innecesarias,
mientras que en Unix es simplemente un volcado de la im=E1gen en memoria.

> >No acostumbro usar flocks, pero le=ED hoy en la ma=F1ana un art=EDculo e=
n The
> >Perl Journal (viene en el Sysadmin de marzo, probablemente lo encuentres
> >a=FAn en alg=FAn Sangrons) que habla acerca de los sem=E1foros... Si vas=
 a tener
> >concurrencia, muchas veces un flock puede quedarse corto.
>
>     Pero deberia de funcionar el flock. Digo, pa' que hago semaforos si e=
l
> sistema debe de ahorrarme ese trabajo, no???

No necesariamente. Hay casos en que un flock puede no ser suficiente. En
el art=EDculo ponen este ejemplo:

1  open(ARCH,'contador.dat') or die 'chas!';
2  flock ARCH, LOCK_EX;
3  $num=3D<ARCH>;
4  close(ARCH);
5  $num++;
6  print "Llevo $num hits";
7  open(ARCH,'>contador.dat') or die 'chin!';
8  flock ARCH, LOCK_EX;
9  print ARCH $num;
10 close(ARCH);

Si entre la l=EDnea 7 y 8 el OS decide cambiar el proceso e inicia una nuev=
a
copia de este mismo programa, esta copia leer=E1 un contador vac=EDo, y cua=
ndo
le toque escribir (tal vez despu=E9s de que la primera copia guarde que
llevas 105334 visitas) va a grabar undef+1=3D1 visitas.

Claro, este es un caso simple, y no demasiado dif=EDcil de evitar... Pero e=
s
una simple demostraci=F3n :)

> >S=ED, a menos que (aprovechando que usas Perl 5.6) uses filehandles l=E9=
xicos,
> >que mueren al salir del bloque en que fueron definidos:
>
> Fijate, acabo de modificar rapidamente mi funcion para hacerlo lexico y e=
n
> windows el mismo archivo la primera vez se tarda 10 segudos, dos m=E1s qu=
e sin
> usar lexicos, y sigue tard=E1ndose mucho m=E1s para la segunda leida...
>
>  open(my $FileHandle,$_[0]) || die "$_[0]: $!";
>  my @FileData =3D <$FileHandle>;   #Aqui esta la bronca...
>  close($FileHandle);
>
>     Espero haber usado bien el filehandle l=E9xico...

Pues... No s=E9 :)

Recuerda que en un sistema multitareas hay muchos factores que pueden
acelerar o ralentizar una operaci=F3n. Y acu=E9rdate tambi=E9n que no conoz=
co
las tripas :)

--=20
Gunnar Wolf - gwolf@campus.iztacala.unam.mx - (+52-55)5623-1118
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF