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

[Alejandro Imass]

Hay algo mal configuirado en el mailman de esta lista, al darle reply
escoje por default a la persona y no a la lista.

---------- Forwarded message ----------
From: Alejandro Imass <ait at p2ee.org>
Date: 2010/3/5
Subject: Re: [caracas-pm] pregunta sobre la librería Threads.pm
To: Jennifer Maldonado <jcmm986 at gmail.com>


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ó:
>>