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

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
  • Comment on Re^7: Should I use threads? Perl/DHCP/Radius

Replies are listed 'Best First'.
Re^8: Should I use threads? Perl/DHCP/Radius
by roboticus (Chancellor) on Aug 25, 2010 at 15:17 UTC

    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

[reply]
[reply]
Re^8: Should I use threads? Perl/DHCP/Radius
by BrowserUk (Patriarch) on Aug 25, 2010 at 15:11 UTC
    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.
[reply]
[reply]

        And? You can mix threads and event loops. Big deal. The question is: why would you?

        You could still employ a man to carry a flag and walk in front of your 200mph hypercar, but it doesn't make sense to do so.

        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]

In Section Seekers of Perl Wisdom