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