http://www.perlmonks.org?node_id=1122864


in reply to ithreads memory leak

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^2: ithreads memory leak
by DNAb (Novice) on Apr 09, 2015 at 16:27 UTC

    I see what you are both saying, I'm just not 100% sure how to make this code any different right now. It's somewhat unique, but it's still totally in beta so I'm fine with revisiting most aspects.

    The use case is as follows: An assortment of showcases are alarmed. To access a showercase a user must press a function key on a keypad, this starts a timer which gives them up to three minutes to open the showcase. If the user doesn't open the showcase, update the database to require another key press, if the user does open the showcase update the point as open in the database and then kill the walking timer, and start the open timer. The open timer lets them keep the door open for ten minutes, if this timer expires then send an alert, otherwise when the user closes the door kill the open timer. I realize this is complicated, I'm trying to give anyone reading this thread an idea of why it is how it is.

    Anyway, as promised here is the code:

    (Fair warning, by anyone's standards it's probably ugly)

    Read more... (24 kB)

[reply]
[d/l]

      First:Ignore anything and everything sundialsvc4 says. He has a proven track record of meaningless, misdirected & pure malicious posts on subjects he has provably no knowledge or understanding of. And in particular, threads.

      then kill the walking timer,

      The fundamental problem with your code is this:

      #! perl -slw
use strict;
use threads;

sub sleeper {
    print "thread started; sleeping";
    $SIG{'KILL'} = sub { print "Thread dieing"; threads->exit(); };
    sleep( 1000 );
    print "Thread dieing";
    threads->detach;
}

my $t = threads->new( \&sleeper );

sleep 5;

print "Killing thread";

$t->kill( 'KILL' )->detach;

print "thread status: ", $t->error();

sleep 100 while 1;

      [download]

      Run that code and watch the process (top or whatever). It immediately creates a thread that just sleeps for a thousand seconds. The main thread then waits for 5 seconds and then (attempts to) kills the sleeping thread. But the thread never sees the "signal" ... until it finishes sleeping.

      This is because those "signals" aren't real signals; but some home-brewed simulation of them that cannot even interrupt a sleep. They (the pseudo-signals), should never have been added to the threads api; and they should never be used!

      And that explains the "memory growth" problem; you are expecting these threads to go away when before you start their replacements; but they simply won't.

      And that's a problem for your architecture which is built around that premise.

      I have 3 solutions for you: one is a quick fix; and the other two will required fairly extensive changes to your program.

      (But its my dinner time right now, so I'll detail them in a while. I just wanted to warn you to ignore sundialsvc4 who has never posted a single line of working code here. Be warned!)

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
      In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
[reply]
[d/l]

        Ah I see this caveat noted in the thread docs now, thank you for clearing this up.

        I'm happy to listen to any suggestions you can offer (when you have free time of course!), and I'm willing to put work into this, assuming it's near my level of competence.

        Again, thanks!

[reply]

In Section Seekers of Perl Wisdom