Thanks. I think that's great piece of information for all the members of
this group.
Do let us know when your module is made avilable on the net.
Coming to point ! I am bit confused :-(
Is it that the POE uses only ports (sockets) to communicate and pass events,
information etc., between different threads ?
If so does it have any effect on the Network (ie.,increase traffic etc.,)
Can we have threads communicating using pipes
( Appologies in Advance . I am not very fimiliar with Unix environment and
Pipes ).
with regards
Rajeev Rumale
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rajeev Rumale
MyAngel.Net Pte Ltd., Phone :
(65)8831530 (office)
#04-01, 180 B, The Bencoolen, Email :
[EMAIL PROTECTED]
Bencoolen Street, Singapore - 189648 ICQ : 121001541
Website : www.myangel.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----- Original Message -----
From: "Jos Boumans" <[EMAIL PROTECTED]>
To: "Rajeev Rumale" <[EMAIL PROTECTED]>
Cc: "Chas Owens" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, June 22, 2001 4:55 PM
Subject: Re: Pooling of objects and session data
> if you say 'multi thread' you say POE....
> it's an excellent module that allows you to multithread in perl, you can
read
> some about it here
> http://www.perl.com/pub/2001/01/poe.html
>
> it will take you a bit to wrap your brain around it, but i assure you it's
worth
> it... of course, feel free to post questions about it to the list
>
> you can get the latest download from either sourceforge.net or from
poe.perl.org
>
> i recently made a ppm for windows to install the latest version, which
should be
> available for public download shortly as well
>
> hth,
>
> Jos Boumans
>
>
>
> Rajeev Rumale wrote:
>
> > Dear Chas,
> >
> > Thank U very much for the suggestion. I am very much convinced with
this
> > and would like to proceed in same direction.
> >
> > I perfer to develop the whole application in a single language, as far
as
> > possible. Since I am quite new to Perl I would like to know if we can
> > write multi-threaded programs in PERL.
> >
> > I would be greatfull if any one can suggest me some good online tutorial
for
> > the same.
> >
> > with regards
> >
> > Rajeev Rumale
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Rajeev Rumale
> > MyAngel.Net Pte Ltd., Phone
:
> > (65)8831530 (office)
> > #04-01, 180 B, The Bencoolen, Email :
> > [EMAIL PROTECTED]
> > Bencoolen Street, Singapore - 189648 ICQ :
121001541
> > Website : www.myangel.net
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > ----- Original Message -----
> > From: "Chas Owens" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, June 21, 2001 7:34 PM
> > Subject: Re: Pooling of objects and session data
> >
> > > On 21 Jun 2001 15:16:19 +0800, Rajeev Rumale wrote:
> > > > Hi,
> > > >
> > > > I need to know if there is any easiest way to keep session data or
> > object
> > > > accross the scripts.
> > > >
> > > > Basically I would like to pool Database connections so that
Parrallel
> > > > running scripts don't open multiple connection with the database.
> > > >
> > > > with regards
> > > >
> > > <snip />
> > >
> > > The only way I can think of to achieve this would be to write a daemon
> > > process in perl (or any other language for that matter) that would be
> > > responsible for accessing the database based on requests (through IPC,
> > > BSD style sockets, files being placed in certain directories, smoke
> > > signals, whatever) and returning the data (again through some
> > > communication method). I have seen production systems (not that I
> > > recommend this) that had a special set of directories named /work/in
and
> > > /work/out. Shell scripts would print sql statements to files in the
> > > /work/in dir and a C daemon would: pick them up, see if they were from
> > > the right owner, discard the invalid files, run the valid ones and put
> > > the results in the /work/out dir. Filenames were based on the pid of
> > > the shell script. The shell script would then sit waiting for a file
> > > with its pid to show up in the /work/out directory.
> > >
> > > In general, if you are having to create hacks like this the problem is
> > > most likely you choice of RDBMS. Enteprise level databases generally
> > > don't have a problem with thousands of concurrent connections.
> > >
> > > --
> > > Today is Boomtime, the 26th day of Confusion in the YOLD 3167
> > > Or is it?
> > >
> > >
> > >
>
>
