i recommend you buy the Perl Cookbook by o'reily
there is a great fork section
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "pierre smolarek" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 19, 2001 2:43 PM
Subject: Re: Do I use fork() for this?
> I'm not sure exactly what 'auto reap' means?
>
> Not being a Unix-ian, coming from DOSland, makes my life quite
> difficult when it comes to understanding Unix.
>
> Cheers again,
> TommyGun.
>
> www.y2kdiary.com
>
> -----Original Message-----
> >From : Pierre Smolarek <[EMAIL PROTECTED]>
> To : [EMAIL PROTECTED]
> CC : [EMAIL PROTECTED] : 19 July 2001 13:39:45
> Subject : Re: Do I use fork() for this?
> :)
> >
> >the daemon is server side and runs in the background. So unless you have
> >shell, you can't start it off that easily.
> >
> >What you could use BUT IT IS EXPERIMENTAL is thread.
> >
> >check it out in perldoc. Its really the easy way to do what you do..
Threads
> >will handle all the forking and communication for your. But be warned..
its
> >very beta and can not be relied on! Threads I not standard and needs to
be
> >compiled in with perl on install. Threads will be standard in perl 6
(long
> >live the dream)
> >
> >until then, I would fork away the way I told you in my earlier email
> >
> >> Is that is the only way to communicate with a $child? Without having
> >> to Kill() it!
> >
> >ideally you would keep a conversation.. but you don't always need to....
you
> >can let it die naturally with 'exit'. Remember to auto reap though. There
is
> >nothing worse then coming back to your box a day later and you see 1000's
of
> >children lost in your system.... :( trust me.. I know too well.. had many
a
> >crash with lack of memory during debugging. I recommend you develop a
fork
> >system off the live server!
> >
> >Pierre
> >
> >
> >----- Original Message -----
> >From: <[EMAIL PROTECTED]>
> >To: ?pierre smolarek? <[EMAIL PROTECTED]>
> >Cc: <[EMAIL PROTECTED]>
> >Sent: Thursday, July 19, 2001 1:30 PM
> >Subject: Re: Do I use fork() for this?
> >
> >
> >> Sounds a bit complicated, for the beta1 version, but I may move to
> >> something like this as my confidence grows.
> >>
> >> Is the 'deamon script' a purely server-side app? This is a bit of a
prob
> >> at them moment as only have FTP for live server and my test box is
> >> in the early stages of dementure.
> >> Would this make it quite awkward to debug? As only have Bindows
running
> >'perl -d ..' from the prompt at the mo.
> >>
> >> I think I'll just have the original search script check for files older
> >than
> >> a couple of hours. (I know this is a really crap way to do the job,
but
> >> I don't care anymore!)
> >>
> >> Is that is the only way to communicate with a $child? Without having
> >> to Kill() it!
> >>
> >> Thanks for the ideas and they are most appreciated,
> >> they just make lazy people like me feel tired (oh crap!).
> >>
> >> Maybe another day I'll feel full of perl-beens.
> >>
> >> TommyGun.
> >>
> >> www.y2kdiary.com
> >>
> >> -----Original Message-----
> >> >From : Pierre Smolarek <[EMAIL PROTECTED]>
> >> To : [EMAIL PROTECTED]; [EMAIL PROTECTED]
> >> Date : 19 July 2001 13:01:58
> >> Subject : Re: Do I use fork() for this?
> >> not really the best way in my opinion....
> >> >
> >> >what you could do is use two scripts.....
> >> >
> >> >first script is the cgi, it does what needs to be done to get the data
> >and
> >> >then pipes it to a deamon script that forks off children for each
> >proccess.
> >> >The cgi then askes the deamon on the status of its child as the child
and
> >> >parent has communication between each other. The child will die a
natural
> >> >death and you could set the deamon to autoreap.
> >> >
> >> >All your cgi will then do is transilate the deamon to the user,
basicly
> >> >saying. ?Sorry.. still busy...? and once the deamon tells you its ok..
> >the
> >> >cgi will read the DBM or whatever you plan to do.
> >> >
> >> >If your a little nerves of all this conversation between deamon and
> >children
> >> >and cgi.. you could use temp files with the status.... and you just
> >delete
> >> >or change the contents of the tmp file... your cgi will just check
whats
> >up
> >> >with the tmp.
> >> >
> >> >make sence?
> >> >
> >> >Pierre
> >> >
> >> >
> >> >----- Original Message -----
> >> >From: <[EMAIL PROTECTED]>
> >> >To: <[EMAIL PROTECTED]>
> >> >Sent: Thursday, July 19, 2001 12:53 PM
> >> >Subject: Do I use fork() for this?
> >> >
> >> >
> >> >> Hello all,
> >> >>
> >> >> I'm currently trying to put a little ?search engine? together for
> >> >> a small web site, basically searching through a bunch of files for
> >> >> matching keywords.
> >> >> As I want a Progress Page while the script is doing its work, I show
> >> >> a page while the script is searching (had to use $| to achieve) and
> >> >> store the results in a DBM.
> >> >> So when the search/progress script is finished I activate a
JavaScript
> >> >> doc.location command to call the script again with diff params,
thus
> >> >> reading the results DBM and outputing page by page.
> >> >>
> >> >> What I want to do is... put a ?kill time? of say 20 mins on the
DBM
> >file
> >> >> so that it gets tidied away. So...
> >> >>
> >> >> $child = Fork() {
> >> >> some code to Sleep(20 mins);
> >> >> then Unlink(results DBM);
> >> >> }
> >> >>
> >> >> What if the client is still accessing the search results at 20 mins?
> >> >> I read through PerlDoc perlfork and it recommends not Kill()ing
> >Children.
> >> >>
> >> >> Can my script, while requests for result pages rain down,
communicate
> >> >> with the $child (richkid ;o), thus sustaining the $child's life?
> >> >>
> >> >>
> >> >> Probably not the most practical way to achieve my objective,
> >> >> but I'm not the best at this programming lark. :o)
> >> >>
> >> >> TommyGun.
> >> >>
> >> >> www.y2kdiary.com
> >> >>
> >> >> -----
> >> >>
> >> >> 20 email addresses from 15,000 domain names - free at
> >> >http://www.another.com
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
>
>>--------------------------------------------------------------------------
-
> >-
> >> >----
> >> >
> >> >
> >> >> --
> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >> >--
> >> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >> >
> >>
> >> -----
> >>
> >> 20 email addresses from 15,000 domain names - free at
> >http://www.another.com
> >>
> >>
> >
> >
> >--
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -----
>
> Express yourself @ another.com
> http://another.com
>
>
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
