in reply to Re^5: Should I use threads? Perl/DHCP/Radius
in thread Should I use threads? Perl/DHCP/Radius

Have a timer ;-) in the main thread loop thru the hash, and make logical descisions for you.

Simple. And wrong!

You're still trying to find a way to wield that lumphammer.

Creating artifical events (polling), is *NEVER* the right approach to solving the problem. Is just spins cycles and wastes resources.

  • Comment on Re^6: Should I use threads? Perl/DHCP/Radius

Replies are listed 'Best First'.
Re^7: Should I use threads? Perl/DHCP/Radius
by zentara (Cardinal) on Aug 25, 2010 at 14:45 UTC
    He will want multiple timers checking different things simulanaeously. Without that ability, he eventually will have deeply nested while loops, that clog up and can't be dynamic enough to change every 10 milliseconds. Deeply nested loops are like human insanity.... people claim they are perfectly sane in their unresponsive deeply nested state, whereas the worlds around them are constantly checking and updating their state, pitying the poor deeply nested while loop.... spinning there, stuck, because their code god did not make them with an eventloop, so that they could understand time. bwahaha

    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh

      Actually BrowserUk was suggesting threads so that he could avoid those deeply nested loops, synchronization, etc. Each thread can do it's job independently of the others. The main thread would have nothing to do except look for work and spawn new threads as required, and (if required) monitor the currently-existing threads.

      ...roboticus

      He will want multiple timers checking different things simulanaeously.

      And that just shows the depth of your misunderstanding.

      Timers do not happen "simulanaeously.". They happen serially. And all on the same thread.

      And if the processing required in response to one of these artificial events takes too long, then you start missing events. So then you have to create more timers and more states and break up the response code into iddy biddy chunks to try and avoid missing events. And then you have to tune those iddy biddy chunks of code each time you move to a different cpu.

      And when your workload increases to the point that your code can no longer keep up with the demand, you move it to new machine with 16 times power; BUT IT DOESN'T HELP ONE JOT!

      It can only utilise 12.5% of your 8-core CPU. Or 6% of your 16-core cpu. or 5% of your 10-core, hyperthreaded cpu.

      Or less than 0.1% of your new 256-core, 1024-thread SMP server.

      Because your single-threaded, event-driven architecture DOESN'T SCALE!

      Your continued attempts to push this ancient, evolutionary dead-end of software architecture, despite that it is so obviously completely unsuited to the realities of modern hardware, is--and I'm sorry to re-use this word, but it is appropriate and measured--asinine.


      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.