Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hi. I got a huge problem with a irc bot i've built. Today i use threads but it's almost impossible to live with due to the memory leaking problem. Is there another tool that can work almost the same as threads. For a brief examle: (a on public sub) 
if (lc substr($text,0,5) eq ".help") {
  my $info = substr($text,6);
  my $auth = autcheck($info, $event->{nick}, $event->{host});
  $helpthr = threads->new(\&help);
  $helpthr->detach;
}

[download]
This is just an example where i tread the help sub. Sometimes i have HUGE subs running on public commands, some takes about 30 mins to complete. Thats why i need threads so the main code wont be locked up and wait for the sub to exit. So ppl can run parallell, Say 5 ppl type help at the same time they should all be served directly.

Is there any other "simple" way to do this? I've tried forks but that didnt work good at all. Been reading a little about POE but just can figure out if it could be a sollution to my problem or not.

Please help a desperate dude out here :)

update (broquaint): fixed formatting

Replies are listed 'Best First'.
Re: Threads Problem!
by liz (Monsignor) on Nov 03, 2003 at 11:57 UTC
    Before making changes to your code, you might want to try forks, a drop-in replacement for threads.pm using fork(). Without the memory problems at the expense of more CPU and latency because sockets are used for communication between threads.

    If you are willing to make changes to your code, of course fork() by itself could probably be used as well.

    Liz

[reply]
      I've tried forks and it works but it doesnt exit the sub the same way as threads do.


      The bot is built on Net::IRC

      Averything is handle with public commands wiht on_public.

      For example a stock exchange checker.

      i do  .stock ericsson from irc.
      Then the bot jumps to a sub and does a alot of prosessing for me and print output to irc. after that is done i just want the sub to die. But this sub just keep goin as another prossess, or they still stay in system like zombies if i kill them. (ps -x)
      i've tried exit(0); return; and also join but nothing gets it goin as it does with threads.

      I probably don't have enuff knowledge to see what the problem is either :(

      All i want is a sub thats runs parallell to other subs and when the sub is done it should just dissapear. Been trying to fix this for 1 month now but no luck :/

      The entire script are made around threads It's 14 371 rows of code in 19 files so rewriting it from scratch would suck hehe

      Someone said that POE::WHEEL could handle it to but i'm not sure. i just want a easy replacement for threads, forks would be real nice if i just could exit the subs the same way as threads does.

      Thank you for your time. Really appreciate it.
[reply]
[d/l]
        I've tried forks and it works but it doesnt exit the sub the same way as threads do.

        Could you elaborate on this? It should behave the same as threads. And I have not been able to reproduce it with a simple case. Are you sure they are zombies? Could it not be that something is keeping the forked processes alive in e.g. a DESTROY subroutine?

        Liz

[reply]
Re: Threads Problem!
by BrowserUk (Patriarch) on Nov 03, 2003 at 12:22 UTC

    You do not give enough information for us t suggest a solution. If youre using earlier than 5.8.1, there are some known problems with memory leaks, but unless you are using large quanities of shared variables and/or not taking precautions to minimized the nadvertant sharing of datastructures and code between your threads, 5.8.0 is also quite useable. If your using earlier than 5.8.0, you should definately upgrade.

    Unfortunately, beyond the sage advice in liz's Things you need to know before programming Perl ithreads, it it quite difficult to try and write down all the things that you need to look for that might be contributing to memory leaks in threaded apps. I know, because I've tried a couple of times. However, it is usually possible to eliminate (or reduce to a trivial minimum), the rate of leakage, but carefully working through the application looking for where things might be inadvertantly being shared in a way that makes it difficult for perl to clean up.

    One thing that you probably shouldn't be doing is creating and destroying threads on a one-shot basis. It is hugely more efficient and creates much fewer possibilities for leaks, to create a pool of threads and dispatch elements of work to them via a queue. It's a somewhat harder way to use threads and would probably mean a fair amount of reworking of your existing application (going by the format of the snippet you posted), but the end result is usually worth the work.

    Sorry to answer in the generic, but in the absence of more information, it is all that is possible.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    Hooray!
    Wanted!

[reply]
      Thanks alot for the info.
      I will have a look at the thread pool and see if that could help me out a lil.
[reply]

Back to Seekers of Perl Wisdom