last thought ... I think the point here is that in java you don't need two processes rather the servlet engine runs and spawns off threads as needed ... so you can share the information freely between threads ...
I was wondering if this is possible in perl? -----Original Message----- From: Daniel Gardner [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 02, 2002 2:44 PM To: Maciejewski, Thomas Cc: 'Hanson, Robert'; Agustin Rivera; [EMAIL PROTECTED] Subject: Re[2]: C vs. Perl Wednesday, January 02, 2002, 7:06:34 PM, Maciejewski, Thomas wrote: > how ? > through CGI? > can you post an example? i can't say i've ever tried to build a perl with threading enabled, but there's always lots of discussion on the mod_perl mailing list about sharing data between processes. take a look at the Cache::* modules, Apache::Session, MLDBM::Sync, or probably a host of others for ways to share data around. none of those modules need mod_perl (even the non-intuitively named Apache::Session) http://search.cpan.org/search?dist=Cache-Cache http://search.cpan.org/search?dist=Apache-Session http://search.cpan.org/search?dist=MLDBM-Sync hth, daniel > -----Original Message----- > From: Hanson, Robert [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 02, 2002 2:09 PM > To: Maciejewski, Thomas; Agustin Rivera; [EMAIL PROTECTED] > Subject: RE: C vs. Perl > "One benifit to running java though ... is that you can easily share > information between your threads" > Same with Perl. > Rob > -----Original Message----- > From: Maciejewski, Thomas [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 02, 2002 2:02 PM > To: 'Brett W. McCoy' > Cc: Agustin Rivera; [EMAIL PROTECTED] > Subject: RE: C vs. Perl > agreed that OO isnt always better but the point that I was trying to make > was that I would rather build more structured code that is easier to > maintain / debug than to worry about the internal speed of a program ... > also wanted to point out that there are other aspects to the percieved speed > of a program like running servlets or in tomcat or whatever .... > One benifit to running java though ... and maybe tomcat does this is that > you can easily share information between your threads ... not sure how > tomcat deals with that ... > -----Original Message----- > From: Brett W. McCoy [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 02, 2002 2:01 PM > To: Maciejewski, Thomas > Cc: Agustin Rivera; [EMAIL PROTECTED] > Subject: RE: C vs. Perl > On Wed, 2 Jan 2002, Maciejewski, Thomas wrote: >> how about all of the issues involved with spawning off processes ... >> >> in java servlets I know this is handled because the servlet is always >> running ... > You mean the servlet container is always running, like Tomcat. >> you may end up with a more efficient system and easier to debug code and > all >> of the other benifits from OO ... pretty much all around better by >> re-writing in java ... rather than c > Bah, OO isn't always the best way. I won't get into a Java vs. C vs. Perl > thing here, but you code in a style which is most suitable for the project > at hand and for the people doing the coding. > -- Brett > http://www.chapelperilous.net/ > ------------------------------------------------------------------------ > If you suspect a man, don't employ him. -- Best Regards, Daniel [EMAIL PROTECTED] ------------------------------------------------------------------------------ This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
