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]

Reply via email to