in reply to Should I use threads? Perl/DHCP/Radius

How can I make several MACs make calls to the API concurrently and all updating the %clients hash safely. Am I even attempting a threadable problem? I have spent quite some time reading perlmonks, perldocs to no avail.

Threads are the perfect solution for this type of problem, where you need some realtime sharing between the threads. The only thing I would add, to yours and BrowserUk's solutions, would be to add an eventloop system in your main program, which can utilize timers to check shared variables on a regular schedule, and do what needs to be done. The threads:shared code already has locking shared variable locking available to you, but if you think about it, you can give each thread it's own hash slice to write to to avoid locking, then have the timer in the main program loop do periodic checking of the hash. Event loops can be done with POE, Tk, Gtk2, GLib, Wx, and many other eventloop systems.

For instance, see Tk-with-worker-threads and Threads-w-Perl/Gtk2 demo and the POE Cookbook. For an example of sharing socket filehandles amoung threads, see Simple threaded chat server

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku flash japh
  • Comment on Re: Should I use threads? Perl/DHCP/Radius

Replies are listed 'Best First'.
Re^2: Should I use threads? Perl/DHCP/Radius
by BrowserUk (Patriarch) on Aug 23, 2010 at 18:48 UTC
    The only thing I would add, to yours and BrowserUk's solutions, would be to add an eventloop system in your main program, which can utilize timers to check shared variables on a regular schedule, and do what needs to be done.

    This is completely and utterly useless advice. There is absolutely no advantage to using an event loop in the main thread for this.

    If there was a requirement to "have the timer in the main program loop do periodic checking of the hash.", that is trivial: 

    my @maclist = qw (
    7D:6D:62:C6:B4:3D 01:12:79:3E:14:2E 80:27:E4:EA:60:74
    E8:06:88:7F:8C:83 01:26:08:E8:B6:5D 34:15:9E:5D:E6:49
    03:1E:64:CE:25:88 01:0C:29:3F:67:1B 01:22:69:76:5D:F4
    64:B9:E8:10:BF:20 01:1D:FE:D4:7F:E0
);

my @threads;

foreach my $mac (@maclist){
    push @threads, threads->create( \&doit, $mac );
}

while( sleep 1 ) {
   ## check %clients and do things.
}

$_->join for @threads;

    [download]

    Recommending the addition of huge, monocultural behemoths like POE or GTK2+glib solely to respond to artificial events generated by a timer is asinine. Like hiring a chainsaw to trim your toenails.

    You seem to be suffering from the 'When you have a lumphammer' syndrome.

    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".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
      I respect your aversion to using timers or the fileevent/select methods of eventloop toolkits, but once you learn to use them, they allow much more flexibility in design. Those 
       
while( sleep 1){  do complex hash checking logic  }

      [download]
      loops can get very cumbersome as the complexity of the hash checking increases. Timers and fileevents make things easier. Also, Glib is only a 260k download, less than most of the pictures you download now-a-days. Glib also works on Win32 and Linux type systems. Glib is the basic class of the Firefox browser out there. Are you suggesting Firefox should use while loops instead?

      Maybe you just an old dog, who is averse to learning "new tricks"? :-)

      I'm not really a human, but I play one on earth.
      Old Perl Programmer Haiku flash japh
[reply]
[d/l]
        I respect your aversion to using timers or the fileevent/select methods of eventloop toolkits, but once you learn to use them, they allow much more flexibility in design.

        I already know how to use them. I was writing event-driven applications for Optical Mark Readers 25 years ago. And event-driven data transfer applications for racks of hand-held terminals 15 years ago.

        And I also know what a pain they are to tune each time the software has to be moved to a different hardware configuration. And how much simpler life became when I could ditch those fussy, fragile event loops that forever need re-tuning and are a nightmare to debug. In favour of writing nice, straight forward linear code, testing and debugging it as a single-threaded app, and then just running multiple copies each in its own thread.

        Timers and fileevents make things easier.

        Sorry, but that is rubbish. You dream up and code some extension to the OPs scenario with events and I'll demonstrate it is easier with threads.

        Maybe you just an old dog, who is averse to learning "new tricks"?

        Not at all. You've just rediscovered an old bone of mine that I've long since discarded as chewed out :)

        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".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      If there was a requirement to "have the timer in the main program loop do periodic checking of the hash.", that is trivial:

      Is what I am doing. But thanks for your advice folks! I am currently figuring out how to synchronize the thread for each MAC with the main thread. Should be interesting!
[reply]
        I am currently figuring out how to synchronize the thread for each MAC with the main thread.

        Could you explain why you need to do that?

[reply]

In Section Seekers of Perl Wisdom