[caracas-pm] pregunta sobre la librería Threads.pm

Jennifer Maldonado jcmm986 at gmail.com
Fri Mar 5 18:17:17 PST 2010


Gracias lo tomaré encuenta :D . La pregunta surgió luego de ver que la
autora de un modulo llamado forks dijo esto:

*"The standard Perl 5.8.0 threads implementation is very memory consuming,
which makes it basically impossible to use in a production environment,
particularly with mod_perl and Apache. Because of the use of the standard
Unix fork() capabilities, most operating systems will be able to use the
Copy-On-Write (COW) memory sharing capabilities (whereas with the standard
Perl 5.8.0 threads implementation, this is thwarted by the Perl interpreter
cloning process that is used to create threads). The memory savings have
been confirmed."*

http://search.cpan.org/~elizabeth/forks-0.16/lib/forks.pm


El 5 de marzo de 2010 16:38, Alejandro Imass <ait at p2ee.org> escribió:

> 2010/3/5 Jennifer Maldonado <jcmm986 at gmail.com>:
> > Muchisimas Gracias a todos.
> > Ahora estoy pensando si usar el método forks.
> > ¿Es cierto que consume menos recursos que la librería threads.?
> >
>
> Para poder contestar esta pregunta es necesario saber qué quieres hacer???
>
> Teoricamente todo lo que se puede hacer con threads se puede hacer con
> procesos (aka fork). Son casi lo mismo[2] y es mas que todo un tema
> filosófico y muy dependiente de la plataforma[1].
>
> En Linux los threads se implementan como LWP (Light-Weight Processes)
> y el api se adhiere al estándar Posix 1003.1c (hasta donde sé).
> Generalmente, el espacio de memoria es compartido entre los threads
> mientras que en los procesos cada proceso es completamente
> independiente, y éstos últimos suelen consumir más recursos (en
> teoría).
>
> Por ejemplo, si vas a "disparar" varios procesos Perl, cada uno tendrá
> su instancia del interpretador, aunque es posible que se compartan
> algunos segmentos de código (librerías en RAM), por lo tanto va a
> consumir mucho más recursos que se disparas muchos threads del mismo
> programa. Adicionalmente, compartir información entre procesos es
> mucho más dificil (y/o lenta) si usas procesos, y en muchas ocasiones
> tienes que recurrir a IPC heredado de Sistema V (System V Inter
> Process Communication) para lograrlo.
>
> Cada uno tiene sus ventajas y desventajas, todo depende del uso. Si tu
> cuello de botella no es CPU sino RAM, los threads pueden ser mejor
> opción. Supongamos que vas a hacer un servidor de red (de cualquier
> cosa) tu tiempo de respuesta es alto pero no consume recursos de CPU
> mientras esperas las respuestas de otros sistemas. Con el modelo de
> procesos a lo mejor se te agota la RAM con tan solo 500 procesos, con
> threads a lo mejor te permite acomodar 10.000. Tanto los threads como
> procesos pueden usar múltiples CPUs, al menos en Linux (no sé en
> HP-UX). Si cada tarea es muy CPU-intensiva entonces es probable que el
> modelo de procesos sea una mejor opción.
>
> El threading _casi siempre_ va a fugar memoria, y en Linux esto es
> especialmente cierto por la forma en que se implementa el
> copy-on-write (ver esta discusión en PM
> http://www.perlmonks.org/?node_id=824655). Si vas a usar threading por
> ejemplo para Apache mod_perl, debes re-iniciar los procesos de vez en
> cuando (
> http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxrequestsperchild)
>
> En definitiva en *nix es casi siempre mejor idea usar procesos a menos
> que tengas alguna razón en particular para usar Threads. Si estás
> haciendo un servidor en red de algún tipo con Perl, te recomiendo que
> veas POE, realmente te puede ahorrar mucho tiempo y dolores de cabeza,
> y casi todo lo que necesitas está hecho ya para POE:
> http://poe.perl.org
>
> Saludos,
> Alejandro Imass
>
>
>
> [1] Por eso es que yo le echo tanta vaina la gente de Java que jura y
> perjura que Java es realmente 100% portable, y quizás lo sea con los
> green threads, pero como todos sabemos eso sería inoperante en un
> ambiente de la vida real ;-) En la realidad siempre tendrán que
> recurrir a Native Threading y Just-In-Time Compiling para que sirva
> para algo, por lo que su portabilidad se va al carajo viejo en la vida
> real.
>
> [2] En la actualidad hay como 3 grandes meta-patrones que de alguna
> forma compiten entre sí: Process, Threads  y EDA/SEDA
> (Event-Driven-Architecture , Staged-Event DA respectivamente). Al
> final del día no son más que patrones de diseño que dependerán que el
> SO realmente haga algo con ello. Por ejemplo, si el timeslicing del
> sistema es preemtive o es tiempo real. Y en honor a la verdad, casi
> todo se reduce a polling de todas formas ;-) asi que todo esto es pura
> teoría. Y cada vez que sale algún genio diciendo que descubrió la
> piedra filosofal, los estudios demuestran que el modelo de procesos
> sigue siendo el más estable, eficiente y efectivo.
>
> > Saludos.
> >
> > El 3 de marzo de 2010 16:15, Ernesto Hernández-Novich <
> emhnemhn at gmail.com>
> > escribió:
> >>
>



-- 
Saludos y un Abrazo.
Jennifer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/caracas-pm/attachments/20100305/95f10135/attachment-0001.html>


More information about the caracas-pm mailing list